The Problem With Generating Documents
You have data in a database and need it in a document. A PDF invoice. A DOCX contract for legal review. An EPUB manual. A PPTX quarterly report. This should be a solved problem by now.
It isn’t. The landscape is fragmented across fundamentally different approaches, and choosing the wrong one means rewriting your document pipeline six months from now when requirements change. A tool that generates perfect PDFs from HTML won’t help when legal needs a Word document they can redline. A template-merge system that works great for invoices falls apart when you need dynamic layouts driven by variable-length data.
There are three architectural approaches to document generation, and every tool on this list falls into one of them:
- Template-merge — design a document in Word or a visual editor, mark where data goes, feed in JSON, get a filled document back. The template is a file. The API is a merge engine.
- HTML-to-PDF — write HTML and CSS, send it to a rendering engine, get a PDF. You control the layout with web technologies. The output is almost always PDF-only.
- Structured content model — define your document as a data structure (JSON blocks describing headlines, paragraphs, tables, images), and the API renders it into one or more output formats. No template files. No HTML.
Each approach makes different tradeoffs. This guide covers the tools worth considering in each category, what they actually do, and where they fall short.
Template-Merge Tools
The oldest approach to document generation. You create a template in a familiar word processor, insert placeholder tags where dynamic data belongs, and an API merges your JSON payload into the template. The output is usually the same format as the template — DOCX in, DOCX out — with optional PDF conversion via LibreOffice.
Carbone.io
Carbone is the most popular open-source template-merge engine. Templates are DOCX, ODT, XLSX, or PPTX files with {d.field} placeholder tags. Upload a template, POST your JSON data, and Carbone merges them and returns a document.
The community edition is free and open source (MIT license). You run it yourself — which means running LibreOffice, because that’s what Carbone uses for rendering and format conversion. The cloud API starts at EUR 29/month for 1,000 documents, with a free tier of 100 documents/month.
Where Carbone fits: teams where non-developers need to edit document layouts. A business analyst can open the DOCX template in Word, rearrange fields, and the API picks up the changes. No code deployment needed.
Where it doesn’t: anywhere you need version control over templates. DOCX files are binary — you can commit them to Git, but the diff is meaningless. Template-data mismatches are silent. Rename a JSON field, forget to update the template tag, and you get a blank where data should be. There’s no compile-time check. The rendering also depends on LibreOffice, which doesn’t match Word’s output pixel-for-pixel. Fonts shift, table widths change, page breaks land differently.
Carbone doesn’t support EPUB output. PPTX templates don’t auto-create new slides when content overflows — you need to size your templates for the maximum possible data.
Docmosis
Docmosis targets enterprise document generation. Like Carbone, it uses Word templates with placeholder tags, but it’s a commercial product with a Java-based rendering engine and both cloud and on-premise deployment options.
Pricing starts at $50/month and scales by pages generated per month. There’s no hard limit — if you exceed your quota, generation continues and you get a bill. For enterprise deployments, pricing is contact-sales.
Docmosis differentiates on performance under load. Its architecture supports parallel rendering across multiple instances, and the rendering engine is purpose-built rather than relying on LibreOffice for everything.
The tradeoff is vendor lock-in and cost. Templates use Docmosis-specific syntax, and the pricing model is designed for organizations that generate thousands of documents monthly. If you’re a small team generating a few hundred invoices, the economics don’t work.
DocuGenerate
DocuGenerate is a newer template-merge API. DOCX templates with {{field}} tags, JSON data in, PDF or DOCX out. Pricing starts at $19/month for 500 documents (Plus plan), with a free tier of 20 documents/month.
It’s simpler than Carbone — fewer features, less configuration — which is either a limitation or a virtue depending on your needs. If you want a straightforward “fill this template with this data” API and don’t need EPUB, PPTX, complex conditionals, or advanced formatting, DocuGenerate does the job without the overhead.
HTML-to-PDF Engines
The web-native approach. You already know HTML and CSS. Why learn a template language when you can write the document as a web page and convert it to PDF?
The answer is CSS Paged Media — or rather, the lack of it. Browsers were built to render infinitely scrolling pages, not fixed-size documents with page breaks, headers, footers, and page numbers. Some tools handle this gap better than others.
DocRaptor
DocRaptor is the hosted version of Prince XML, the gold standard for HTML-to-PDF conversion. Prince actually implements the CSS Paged Media specification — @page rules, named pages, running headers and footers, proper widows and orphans control. The output quality is genuinely the best you can get from HTML.
Pricing starts at $15/month for 125 documents. A free tier provides 5 documents/month plus unlimited watermarked test documents for development.
The catch: CSS Paged Media is its own world. It looks like CSS, but properties like prince-bookmark-level are Prince-specific extensions. You’re writing CSS that only one engine renders, and debugging means iterating against Prince — not your browser’s DevTools.
DocRaptor outputs PDF and XLS. That’s the full list. If you need DOCX, EPUB, or PPTX, you need different tooling for each format.
For teams already fluent in CSS Paged Media, DocRaptor is the obvious hosted choice. For everyone else, the learning curve is real and the format limitation is hard.
PDFShift
PDFShift is a simpler HTML-to-PDF API. Send HTML or a URL, get a PDF. It uses a Chromium-based renderer rather than Prince XML, so the output quality is browser-grade — good for most use cases, but without CSS Paged Media support.
Pricing is credit-based starting at $9/month, where each credit covers one conversion up to 5 MB. The free tier provides 50 credits/month.
PDFShift is straightforward for basic HTML-to-PDF conversion. If you don’t need paged media features and want a quick API without running your own headless browser, it works. But it’s PDF-only, and the Chromium renderer means the same limitations as Puppeteer — no real page numbers, no running headers, no @page rules.
Nutrient
Nutrient (formerly PSPDFKit) is a broader document SDK that includes PDF generation alongside viewing, annotation, and form-filling capabilities. It’s a commercial product with contact-sales pricing.
If your application needs a full document lifecycle — generate, display, annotate, sign, store — Nutrient covers more of that chain than a pure generation API. But it’s also significantly more complex and expensive than a focused generation tool. For teams that just need to create documents from data, Nutrient is overkill.
Structured Content APIs
A different model entirely. Instead of starting with a visual template or HTML, you describe the document as structured data — typically JSON — and the API renders it. No files to manage, no HTML to write, no rendering engine quirks to debug.
Iteration Layer
The Iteration Layer Document Generation API builds documents from a JSON content model. You define your document as an array of blocks — headlines, paragraphs, tables, images, lists, grids, QR codes, barcodes — and the API renders it into your chosen format.
Block types cover the building blocks of professional documents:
- paragraph — text with full style control and markdown support
- headline — h1 through h6 with configurable styles
- image — embedded from URLs with width and height control
- table — header rows, body rows, per-cell content, border and style configuration
- grid — 12-column layout for multi-column content within a single page
- list — ordered and unordered with nesting
- table-of-contents — auto-generated from headlines with configurable depth and dot leaders
- page-break — explicit page boundaries
- separator — horizontal rules with style options
- qr-code — generated from any value, with size and color control
- barcode — six formats including Code 128, EAN-13, and Codabar
Four output formats from a single content model: PDF, DOCX, EPUB, and PPTX. Define your document once, choose the format at render time. The same quarterly report definition produces a PDF for email, a DOCX for stakeholders who want to annotate, an EPUB for long-form reading, and a PPTX for the board meeting.
Custom fonts are uploaded as base64-encoded TTF, OTF, WOFF, or WOFF2 files with explicit weight and style declarations. Your brand typeface renders identically across all four output formats — no font substitution, no system font fallbacks. Headers and footers support text, images, and auto-incrementing page numbers. Nineteen page size presets cover A0 through A6, Letter, Legal, Tabloid, and more, with custom dimensions available.
The document definition is JSON. It lives in your codebase, goes through code review, and can be generated programmatically from any data source. No binary template files, no LibreOffice dependency, no HTML rendering quirks. Every property is explicit in the request payload.
Where it fits: teams that need multiple output formats from a single source of truth, or anyone building document generation into a pipeline where templates-as-files are a liability. If your document structure is driven by data — the number of sections varies, tables grow based on query results, content blocks are assembled conditionally — the block model handles that naturally because it’s just JSON you construct at runtime.
Self-Hosted and Open Source
If you need to keep document generation inside your infrastructure — for compliance, data residency, or cost reasons — these tools run on your own servers.
Gotenberg
Gotenberg is a Docker container that wraps Chromium and LibreOffice behind a REST API. Send HTML and get a PDF via Chromium. Send a DOCX and get a PDF via LibreOffice. Merge multiple PDFs. It’s the Swiss Army knife of self-hosted PDF conversion.
It’s free, open source, and well-maintained — currently at version 8 with regular Chromium updates.
The cost is operational. The Docker image is over 1 GB. Each container runs a full Chromium instance and a full LibreOffice installation, consuming 500+ MB of RAM at idle. Scaling means running more of these heavy containers. Chromium gets CVEs regularly, so you rebuild and redeploy when Gotenberg updates. Custom fonts require a custom Docker image with font files baked in.
Gotenberg converts to PDF. It doesn’t generate documents from structured data — you still need to produce the HTML or Office file that Gotenberg then converts. And the output is always PDF. Need a DOCX from structured data? Different tool. Need an EPUB? Different tool again.
For teams with existing Docker infrastructure that need a reliable self-hosted PDF converter, Gotenberg is the standard choice. Just budget for the operational overhead.
Puppeteer PDF
Puppeteer isn’t a document generation tool — it’s a Node.js library for controlling headless Chrome. But page.pdf() is many developers’ first encounter with programmatic PDF generation, and it’s worth understanding why it works for prototypes and breaks in production.
Each Chromium instance consumes 200–300 MB of RAM. Chromium doesn’t support CSS Paged Media, so you get no native page numbers, no running headers and footers, no reliable page-break-inside: avoid across nested elements. The headerTemplate and footerTemplate options exist but are limited — HTML strings injected into a narrow strip that can’t reference the document content.
Puppeteer is free and runs anywhere Node.js runs (with a Chromium binary). For a weekend project or internal tool generating a few PDFs a day, it works. For production workloads needing professional document output, the infrastructure tax and rendering limitations add up fast. Serverless deployment is particularly painful — Chromium’s binary is too large for most Lambda layers, and cold starts are measured in seconds.
PDF only. No DOCX, no EPUB, no PPTX.
WeasyPrint
WeasyPrint is a Python library that converts HTML and CSS to PDF. Unlike Puppeteer and Gotenberg, it doesn’t run a browser — it has its own rendering engine with broader CSS Paged Media support than Chromium.
That means proper @page rules, page margins, and named pages work out of the box. For Python teams, it’s the most capable open-source option for generating paginated PDFs from HTML.
The limitations: WeasyPrint cannot execute JavaScript. If your HTML relies on any client-side rendering — charting libraries, dynamic content — it won’t work. Performance degrades on complex multi-page documents with many fonts and images. It’s a library, not a service, so you’re responsible for hosting, scaling, and managing dependencies (including Cairo and Pango, which can be finicky to install).
WeasyPrint is a good fit for Python-centric teams generating simple to moderately complex PDFs — reports, invoices, certificates. If you need high throughput, JavaScript execution, or non-PDF formats, look elsewhere.
Typst
Typst is a modern typesetting system — think LaTeX, but with a syntax designed in this century and compilation measured in milliseconds instead of seconds.
The compiler is free and open source (written in Rust). You write .typ files using Typst’s markup language, and the compiler produces PDF output. It supports conditionals, loops, functions, and data loading from JSON, CSV, and XML — which means you can build document templates in Typst and populate them from external data.
Where Typst shines: technical documents, academic papers, and anything with heavy mathematical notation. Compilation is near-instant, the output quality rivals LaTeX, and the language is far more approachable.
Where it doesn’t: Typst outputs PDF only. No DOCX, no EPUB, no PPTX. The template language is Typst-specific — your team needs to learn it. And while you can load data programmatically, the generation workflow is compile-a-file, not call-an-API. Integrating Typst into a web application means running the compiler as a subprocess or using the WebAssembly build.
For teams producing technical documentation or reports where PDF is the only format that matters and compilation speed is critical, Typst is worth a serious look. For multi-format document generation driven by application data, it’s the wrong tool.
Visual Editor Platforms
Some teams want a drag-and-drop editor for designing document templates, with an API for filling them with data at runtime. These tools prioritize the design experience over developer ergonomics.
CraftMyPDF
CraftMyPDF provides a browser-based visual editor for designing PDF and image templates. Drag components onto a canvas, bind them to data fields, and call the API with JSON to generate filled documents.
Pricing is credit-based — 1 credit per PDF or image generation. The Lite plan costs $29/month for 1,200 credits. A free tier is available.
The visual editor is CraftMyPDF’s main selling point. If your team includes designers or business users who need to create and modify templates without touching code, the drag-and-drop interface is more accessible than writing JSON or HTML.
The limitation: output is PDF and images only. No DOCX, no EPUB, no PPTX. Templates live in CraftMyPDF’s editor — they’re not files in your repository. The API is a rendering endpoint, not a document construction API. Your templates are tied to their platform.
PDF Generator API
A similar visual-editor approach. Design templates in a browser, call an API with data. Useful for teams that need non-developers to manage template layouts. The same format limitations apply — primarily PDF output, with templates locked to the platform.
Enterprise Document Automation
For organizations processing millions of documents with complex compliance requirements, there’s a tier of tools built for enterprise scale and enterprise budgets.
Aspose
Aspose provides document processing SDKs across nearly every format — Word, Excel, PowerPoint, PDF, email, and more. The SDKs are available for .NET, Java, C++, Python, and Node.js. There’s also a cloud API.
Aspose is comprehensive. If you need to programmatically manipulate a DOCX at the level of individual paragraphs, merge cells in an XLSX, or extract text from a PPTX — Aspose has an SDK for it. The tradeoff is complexity and cost. Each format is a separate product with separate licensing. Pricing starts in the hundreds per month and scales into the thousands for enterprise deployments.
For teams that need deep format-level manipulation (not just generation), Aspose is one of the few options that covers the full Office format landscape.
Apryse
Apryse (formerly PDFTron) focuses on PDF manipulation — viewing, annotation, redaction, form filling, and generation. Like Nutrient, it’s a full document lifecycle SDK rather than a generation-only tool. Enterprise pricing, contact sales.
If your application is PDF-centric — a document management system, an e-signature platform, a compliance tool — Apryse covers generation plus everything that happens after. For teams that just need to create documents, it’s overbuilt and overpriced.
Adobe Document Generation API
Adobe Document Generation is part of the Adobe PDF Services platform. It uses Word templates with Adobe-specific tags, merges them with JSON data, and outputs PDF. It integrates with the broader Adobe ecosystem — analytics, sign, experience manager.
If you’re already in Adobe’s ecosystem, the integration story is compelling. If you’re not, adopting Adobe’s platform for document generation alone is a heavy commitment with enterprise pricing to match.
Brief Mentions
- Anvil — document generation plus e-signatures and workflows. Useful if you need the full document lifecycle in one vendor. PDF-focused.
- Api2Pdf — a thin wrapper around headless Chrome, LibreOffice, and wkhtmltopdf. Cheap and simple, but you inherit the limitations of whichever engine you choose.
- Documentero — DOCX template merge with a simple API. Small-scale alternative to Carbone if you don’t need the open-source edition.
Comparison Table
| Tool | Approach | Output Formats | Self-Hosted | Free Tier | Starting Price |
|---|---|---|---|---|---|
| Carbone.io | DOCX/ODT template merge | DOCX, ODT, XLSX, PDF, PPTX | Yes (OSS) | 100 docs/mo | EUR 29/mo |
| DocRaptor | HTML-to-PDF (Prince XML) | PDF, XLS | No | 5 docs/mo | $15/mo |
| Gotenberg | HTML/Office-to-PDF (Docker) | Yes (OSS) | Unlimited (self-hosted) | Free | |
| Iteration Layer | JSON content model | PDF, DOCX, EPUB, PPTX | No | — | — |
| Puppeteer PDF | HTML-to-PDF (Chromium) | Yes (OSS) | Unlimited (self-hosted) | Free | |
| WeasyPrint | HTML-to-PDF (Python) | Yes (OSS) | Unlimited (self-hosted) | Free | |
| Typst | Typst markup-to-PDF | Yes (OSS) | Unlimited (self-hosted) | Free | |
| CraftMyPDF | Visual editor + API | PDF, images | No | Yes | $29/mo |
| Docmosis | Word template merge | DOCX, PDF, ODT | Yes | Trial only | $50/mo |
| DocuGenerate | DOCX template merge | PDF, DOCX | No | 20 docs/mo | $19/mo |
| PDFShift | HTML-to-PDF (Chromium) | No | 50 credits/mo | $9/mo | |
| Nutrient | SDK (view, edit, generate) | Yes | Trial only | Contact sales | |
| Aspose | SDK (multi-format) | All Office + PDF | Yes | Trial only | Contact sales |
| Apryse | SDK (PDF lifecycle) | Yes | Trial only | Contact sales | |
| Adobe Doc Gen | Word template merge | No | Trial only | Contact sales |
How to Choose
The right tool depends on who maintains your templates, what formats you need, and where you want to run the infrastructure.
Business users need to edit templates without developer involvement? Carbone.io. The DOCX template model lets anyone with Word make changes. Accept the tradeoff of binary files and LibreOffice rendering quirks.
Best possible PDF quality from HTML? DocRaptor. Prince XML’s CSS Paged Media support is unmatched. The output is as close to print-quality as you’ll get from HTML. Budget for the learning curve on paged media CSS.
Already have HTML templates and need self-hosted? Gotenberg. It’s the most battle-tested self-hosted PDF converter. Accept the operational overhead of running Chromium and LibreOffice in Docker.
Need DOCX, EPUB, PPTX, and PDF from a single content definition? Iteration Layer. Four output formats from one JSON content model. No template files, no rendering engine dependencies, no format-specific reimplementation. The block model means your document structure lives in code, goes through version control, and assembles dynamically from data.
Python-only stack and lightweight requirements? WeasyPrint. Native CSS Paged Media support without a browser dependency. Keep expectations calibrated for throughput and document complexity.
Technical documents where compilation speed matters? Typst. Millisecond compilation, LaTeX-quality output, modern syntax. PDF only, and your team needs to learn the language.
Enterprise with existing Microsoft ecosystem and compliance requirements? Docmosis for template-merge at scale, or Aspose if you need deep programmatic manipulation of Office formats.
Just need simple HTML-to-PDF without infrastructure? PDFShift for a quick hosted solution, or Api2Pdf if you want to choose your rendering engine.
What to Watch For
Regardless of which tool you pick, a few things tend to bite teams after the initial integration:
- Format expansion. The document that starts as PDF-only inevitably needs a DOCX version six months later. If your tool only outputs PDF, that’s a second integration project — or a migration.
- Font consistency. Every tool handles fonts differently. Tools that depend on LibreOffice or Chromium inherit those engines’ font rendering. Custom brand fonts may require explicit installation, base64 embedding, or a custom Docker image.
- Template sprawl. Template-merge systems grow one template per document variation. Twenty invoice templates for twenty clients. The maintenance cost is proportional to the count.
- Rendering fidelity. A DOCX designed in Word will render differently in LibreOffice. HTML styled for Chrome will render differently in Prince. Test early with real data, not placeholder content.
- Scaling characteristics. Tools that wrap desktop applications (Chromium, LibreOffice) scale by running more instances of heavy processes. API-based tools scale on the vendor’s infrastructure. The cost model is different even when the per-document price looks similar.
Pick the tool that matches your output format requirements today and leaves room for the formats you’ll need tomorrow. Start with the Iteration Layer docs if multi-format output from structured data fits your use case.