wkhtmltopdf alternative
wkhtmltopdf is not a competitor. It is what a great many people are still using, and the reason they are searching for a replacement is usually one of two things.
It is archived. The GitHub repository states: "This repository was archived by the owner on Jan 2, 2023. It is now read-only." (checked 2026-08-08). No fixes, no security updates, no new platform builds.
Its engine predates modern CSS. It renders with Qt WebKit, a fork from before flexbox and grid existed. The failure mode is the dangerous one: a modern layout does not error, it collapses quietly into stacked blocks. Nothing in your test suite notices, and the person who designed the document finds out late.
What actually changes
| Renderpaper | wkhtmltopdf | |
|---|---|---|
| Maintained | Yes | No — archived January 2023 |
| Engine | Current Chromium | Qt WebKit, pre-flexbox |
| Flexbox and grid | Full | No |
| Web fonts | Yes | Unreliable |
| Runs entirely offline, no network call | No | Yes |
| Cost | Plan allowance | Free |
| Binary to install and ship per architecture | No | Yes |
| arm64 support | N/A | Poor — a common deployment wall |
| Documents leave your infrastructure | Yes | No |
Two rows there are wins for wkhtmltopdf and they are not small ones: it is free, and nothing leaves your network.
When keeping wkhtmltopdf is reasonable
The document is simple and frozen. A receipt with a table and no layout to speak of, generated by code, redesigned never. wkhtmltopdf renders it correctly and will keep doing so.
Documents must not leave your infrastructure. A hosted API is the wrong shape for that requirement, full stop. Self-hosted Chromium — Gotenberg, or Puppeteer in your own container — is the replacement to look at, not this.
Budget is zero. Free is a feature.
When to move
Somebody redesigned the document and it broke. This is the usual trigger. If the new design uses grid or flexbox — and any design produced this decade does — wkhtmltopdf cannot render it and no amount of CSS tweaking will change that.
You are deploying to arm64. Builds are thin and the project is archived, so this does not improve.
The archived status is now a compliance problem. An unmaintained dependency processing untrusted input is a finding waiting to be written up.
Migrating from wkhtmltopdf
The good news is that your input is already HTML, so there is no template rewrite. The work is:
- Replace the shell-out with an HTTP call. Whatever built the HTML still builds it; only the "turn this into a PDF" step changes.
- Re-check the CSS. Templates written for wkhtmltopdf often contain workarounds for things it could not do — table-based layout instead of flexbox, absolute positioning instead of grid. They still render, so this is optional, but the workarounds can now go.
- Move the header and footer.
--header-htmland--footer-htmlhave no equivalent here; Renderpaper has no header or footer options at all. The CSS technique in repeat a header on every page replaces both, and page numbers come from CSS margin boxes.
Point 3 is the only genuinely fiddly part, and it is the one thing to check before committing to the move.
Try it
Paste your existing template into https://renderpaper.com/try and see whether it
renders the way you meant. No account.