Alternatives
Moving off wkhtmltopdf
A command-line tool that renders HTML to PDF using an embedded Qt WebKit build. For a decade it was the default way to turn a web page into a document, and it is still wired into a great many invoice and report pipelines.
Why teams move
- It is no longer maintained. The repository was archived in January 2023 and the GitHub organisation followed in July 2024 — there is nobody to file a bug with.
- The engine is frozen at a Qt WebKit build far behind modern browsers. Flexbox behaves inconsistently, CSS Grid is absent, and custom properties do nothing — so a stylesheet that works in a browser may not survive the render.
- CVE-2022-35583 is a server-side request forgery rated 9.8 critical. The advisory lists no patched version, so teams that still use wkhtmltopdf need to mitigate that input path themselves.
- It renders whatever HTML it is handed. Pagination remains a property of your HTML and CSS, so long-table behaviour has to be designed and tested in the calling application.
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.
| wkhtmltopdf | pdfs.build | |
|---|---|---|
| What you author | HTML and CSS, rendered by a frozen Qt WebKit build. | A design with a schema, edited in plain English. |
| What decides page breaks | Your stylesheet, on an engine with no CSS Grid and no custom properties. | The design states them; the engine composes to them. |
| As the data grows | Defined by your HTML and CSS, then tested against the legacy engine. | The ordinary case. Each design records what it does. |
The checkable parts
Claims worth verifying rather than taking on trust — each links to its source, checked September 2026.
-
Repository archived on 2 January 2023; read-only since.
wkhtmltopdf on GitHub ↗ -
Last stable release 0.12.6, June 2020.
Releases ↗ -
CVE-2022-35583 — SSRF, CVSS 9.8 critical; the advisory lists no patched version.
GitHub Advisory Database ↗
What is different here
Nothing to operate, nothing to patch
Rendering happens behind an HTTPS endpoint. There is no binary pinned to an old system library, no base image to rebuild when an advisory lands, and no engine frozen at 2012.
Pagination is stated, not inferred
Every design declares what repeats, what grows, what holds position and what may break across a page. The behaviour that wkhtmltopdf leaves to your CSS is written down and testable here.
Data in, document out
You send JSON rather than assembling an HTML string. The template holds the layout, so escaping bugs and string-concatenated markup stop being part of your document pipeline.
When to stay with wkhtmltopdf
It is often the right answer. If any of these describe you, this is not a migration worth making.
- You render trusted, static HTML on an isolated box, the output already looks right, and you can accept an unmaintained dependency.
- You need a self-hosted binary with no outbound network calls, and an API is disqualified on that basis alone.
What moving involves
- 1 The document is redrawn as a template rather than ported. There is no HTML-to-template converter, and a mechanical translation of a 2012-era stylesheet would carry over the problems you are leaving.
- 2 The data you already assemble for the HTML becomes the JSON payload, usually with little change — the same fields, without the markup around them.
- 3 A .docx of the existing document can be imported as a starting point if one exists.
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