Gotenberg alternative
Gotenberg is a well-built, actively maintained, open-source Docker service that converts HTML, Markdown and Office documents to PDF. It uses Chromium, and so does this. There is no rendering-quality argument to make between them.
The difference is that Gotenberg is infrastructure you run, and it does more formats than this does.
The honest table
| Renderpaper | Gotenberg | |
|---|---|---|
| Engine | Chromium | Chromium (plus LibreOffice for Office formats) |
| Word, Excel, PowerPoint to PDF | No | Yes |
| Markdown to PDF | No | Yes |
| Merge and split PDFs | No | Yes |
| Documents leave your infrastructure | Yes | No |
| Cost | Plan allowance | Free — you pay in infrastructure |
| Something to deploy, monitor, update, scale | No | Yes |
| Stored templates, editable without a deploy | Yes | No |
| Editor for non-engineers | Yes | No |
Gotenberg wins four of those rows outright, and one of them — Office documents — is a whole category this service does not attempt.
When to run Gotenberg
Documents must not leave your infrastructure. Decisive.
You need Office conversion. Word and Excel to PDF is a real requirement in a lot of businesses, and there is no answer to it here.
You need to merge or split PDFs. Also not offered here.
You already run Kubernetes and adding a service is routine. Then Gotenberg is mostly free, and "free" is a strong argument.
When Renderpaper fits better
You do not want to operate it. A container is not much until it is: memory limits sized against a document nobody predicted, autoscaling for a monthly invoice run, an upgrade that changes rendering subtly, on-call for a thing that prints invoices.
The document should be editable without a deploy. This is the difference that is not about hosting. With Gotenberg the template lives in your repository, so changing a margin is a pull request, a review and a release. Renderpaper stores the template and gives it an editor; your code sends the same JSON either way.
The header problem, specifically
If you arrived here because of Gotenberg's header and footer behaviour, know that moving does not fix it by giving you a better header option — Renderpaper has no header or footer options at all.
Chromium renders headerTemplate in an isolated context that cannot reach the
page's stylesheet, so Vite- or Tailwind-injected CSS never arrives; inlining the
built stylesheet then exceeds Chromium's size limit for it. Gotenberg's maintainer
has closed this as unfixable, correctly — it is Chromium's behaviour, not theirs.
The fix is a technique rather than a product: put the repeating content in an outer
table's thead so it flows with the document and your own CSS applies. It works in
Gotenberg too. It is written up with measurements in
repeat a header on every page, and page
numbers come from CSS margin boxes.
If that recipe solves your problem, you may not need to migrate at all. That is a strange thing for this page to say and it is the truth.
Migrating from Gotenberg
Same engine, so the HTML and CSS are unchanged. Replace the multipart form post to
/forms/chromium/convert/html with a JSON post, and move @page rules into the
document if they were being set through options.
Try it
https://renderpaper.com/try — no account.