Alternatives
Moving off Carbone
A report generator where the template is an ordinary .docx or .odt containing `{d.field}` markers. You supply JSON, it fills the document, and LibreOffice converts the result to PDF. The core is open source and it emits xlsx, docx and other formats as well as PDF.
Why teams move
- PDF output goes through LibreOffice, so fidelity depends on how faithfully it renders your document — and that is a separate program with its own layout opinions between your template and the file a customer sees.
- Word is a page-oriented editor but not a precise one. Documents that must hit an exact position on a page are harder to pin down than in a system where the layout contract is explicit.
- Running it yourself means operating LibreOffice in production — a heavy dependency to install, sandbox and keep patched.
- Word templates are hard to review. A layout change arrives as a modified binary, so there is no meaningful diff and no small pull request.
Side by side
Three properties that do not change week to week. No price columns and no feature checkmarks — those go stale quietly, and a comparison that misstates the other tool is worse than none.
| Carbone | pdfs.build | |
|---|---|---|
| What you author | A .docx or .odt carrying {d.field} markers. | A design with a schema, edited in plain English. |
| What decides page breaks | Word's layout, then LibreOffice's reading of it. | The design states them; the engine composes to them. |
| As the data grows | The document reflows as Word would, through a second conversion step. | The ordinary case, in one step, with the behaviour written down. |
The checkable parts
Claims worth verifying rather than taking on trust — each links to its source, checked September 2026.
-
Templates are docx/odt with mustache-style `{d.x}` markers; PDF conversion requires LibreOffice.
carboneio/carbone on GitHub ↗
What is different here
One engine, not two
The document is compiled directly to PDF. There is no office suite in the middle whose rendering you have to trust and keep in step.
Reflow is stated, not implied
What repeats, what grows and what may not split is written down per design, rather than being whatever Word does when the content gets longer.
Reviewable changes
Templates are text. A change can be read, diffed and discussed instead of arriving as a new binary.
When to stay with Carbone
It is often the right answer. If any of these describe you, this is not a migration worth making.
- Your document authors work in Word and would not accept anything else. That is a real constraint and Carbone respects it better than this product does.
- You need xlsx, docx or pptx output, not just PDF. This product renders PDFs only.
- You want an open-source core you can run and modify yourself, with no third party in the document path.
What moving involves
- 1 A .docx can be imported directly and converted into a template with a schema, so an existing Carbone template is often the starting point rather than a rewrite.
- 2 The JSON you already pass maps closely — `{d.field}` markers and schema fields are the same idea with different syntax.
- 3 The LibreOffice dependency comes out of your infrastructure with it.
The API reference covers authentication, the render call and error handling; the template gallery has designs to start from rather than a blank page.
Other migrations
Render one and compare
Free tier includes 2 templates and 50 watermarked PDF renders per month. No credit card required.
Start building free