JSON in. Native PPTX, DOCX, XLSX, and PDF out. The only PPTX library with a flexbox layout engine. No LibreOffice. No Chromium.
[01] What breaks
The problems are consistent: files trigger repair dialogs, layouts drift when content gets longer, mainstream JavaScript spreadsheet libraries still cannot create the charts teams expect, and DOCX-to-PDF often means dragging LibreOffice into the stack.
[02] Failure modes
These are the points where document generation stops feeling like a utility and starts becoming product infrastructure.
| Capability | Why it breaks | PaperJSX angle | Go deeper |
|---|---|---|---|
| Files that need repair | OOXML packaging is brittle, and repair-dialog issues stay open across the ecosystem for years. | Validation happens before build, with a stronger structural focus on output that opens cleanly. | PptxGenJS repair comparison |
| Layouts that break when data changes | Most PPTX libraries still require manual x/y/w/h coordinates that do not adapt when content length changes. | Yoga drives PPTX and PDF layout, so elements reflow instead of forcing coordinate-first authoring. | PPTX layout comparison |
| No way to create Excel charts in open-source JavaScript | ExcelJS remains strong for workbook manipulation, but chart creation is still missing. | XLSX generation includes native OOXML charts in free and expands from there in Pro. | ExcelJS chart comparison |
| LibreOffice in Docker for DOCX to PDF | Conversion often gets pushed to an external office runtime with operational weight and layout risk. | DOCX to PDF stays in JavaScript, using the same document pipeline instead of a separate office process. | DOCX to PDF conversion |
[03] Compare
These are the decisions that matter once the file has to survive real recipients, edits, and repeat generation.
PPTX comparison
Reflow versus manual coordinates.
PPTX comparison
Stay in Python, or switch because layout really changes the result.
XLSX comparison
Chart generation from scratch versus workbook manipulation.
PDF comparison
What changes when PDF stops being a simple export.
[04] Same API shape
The playground starts with a PPTX example, but the idea is the same across the engines: define the document as structured data and get a native file back.
POST /api/playgroundContent-Type: application/json{"sourceSchema": "protocol_v2","document": {"version": "2.0","title": "Q2 Board Update","accentColor": "#5A7A9B","slides": [{"slideType": "title-body","title": "Q2 Board Update","body": ["Revenue up 34% QoQ","NRR reached 118%"]},{"slideType": "kpi-grid","title": "Key Metrics","items": [{ "label": "ARR", "value": "$2.4M", "trend": "up" },{ "label": "NRR", "value": "118%", "trend": "up" }]}]}}
HTTP/1.1 200 OKContent-Type: application/json{"data": {"pptx": "<base64 native .pptx>","previews": ["<slide-preview>", "..."],"slideCount": 2}}
[05] Four engines
Each engine is format-specific, but the buying idea is the same: structured input, native files out, and fewer post-generation fixes in the workflow.
PPTX
Built for decks that have to reflow as content changes and still stay editable after handoff.
DOCX
Built for generated Word files that need structure, templates, and page-aware behavior without collapsing into export hacks.
XLSX
Built for spreadsheet deliverables that need native charts, formulas, and workbook structure instead of patched exports.
Built for PDFs that need layout discipline, typography, and downstream business features instead of just printing cleanly.
[06] Differentiators
This is the shortest honest summary of where PaperJSX diverges from the rest of the category.
| Capability | PaperJSX | Competitors |
|---|---|---|
| PPTX layout engine | Yoga WASM flexbox | Manual positioning |
| PPTX line breaking | Knuth-Plass in free tier | Basic greedy wrapping |
| XLSX chart creation in open-source JS | 5 types in free | Still missing in ExcelJS |
| DOCX pagination engine | Widow/orphan and table continuation in Pro | Usually deferred to Word on open |
| PDF typography | HarfBuzz WASM in Pro | Lighter OpenType handling |
| DOCX to PDF | Pure JavaScript | Often LibreOffice-based |
| Multi-format MCP server | First-party package across 4 formats | Usually single-format or third-party |
[07] Built for
PaperJSX is strongest when the document itself is part of the product: recurring QBRs, customer-facing exports, governed PDFs, generated spreadsheets with charts, and workflows where agents need to hand back native office files instead of screenshots.
Prove the workflow in Playground first. Move into the packages once the native file does what your current stack does not.
