Alternatives

wkhtmltopdf alternative: what to use now that it is archived

By the Dynamic Document API team · Tested on 1 November 2026 · Last updated 1 November 2026

wkhtmltopdf turned HTML into PDF for more than a decade, and many invoice and report pipelines still run on it. Its repository has been archived since January 2023, and its engine is the WebKit of Qt 4.8. We rendered the same two HTML files with wkhtmltopdf 0.12.6 and with headless Chrome: twelve of twelve modern CSS and JavaScript features failed in wkhtmltopdf and worked in Chrome.

Below are the results, the alternatives, and a table that maps every common wkhtmltopdf option to an API parameter. The test files are public, so you can repeat it.

Is wkhtmltopdf still maintained?

No. The main repository, wkhtmltopdf/wkhtmltopdf, was archived on 2 January 2023, and the packaging repository that builds the binaries followed on 28 August 2023. The last release is 0.12.6 from 10 June 2020; the 0.12.7 that the project's status page announced never appeared. The same page explains why: wkhtmltopdf is built on QtWebKit, Qt 4 has not been supported since 2015, and QtWebKit was removed from Qt in 2016.

Two vulnerabilities matter if you still run it:

• CVE-2020-21365 (CVSS 7.5): versions up to 0.12.5 let crafted HTML read local files. That is why 0.12.6 blocks local file access by default, and why so many configurations carry --enable-local-file-access, which opens it again.
• CVE-2022-35583 (CVSS 9.8): in 0.12.6, an iframe in the HTML makes the server request any address, including internal ones. There is no release after 0.12.6, so there is no fix.

The status page puts it plainly: do not use wkhtmltopdf with any untrusted HTML. For new work it recommends WeasyPrint, Prince or Puppeteer.

The test: same HTML, two engines

We wrote two self-contained HTML files, with the font embedded so neither engine had to load anything:

• A feature test with twelve CSS and JavaScript features that templates use today, plus two controls written the way older engines expect. Where a test can check itself, it turns green when the feature works and stays red when it does not.
• A two-page invoice written like a current template: a flexbox header, a grid address block, CSS variables for the brand colour, a WOFF2 web font, a table that runs over a page break and a due date set by a short script.

Both files went through wkhtmltopdf 0.12.6 (with patched Qt), the official macOS build, with its default settings apart from A4 and 15 mm margins, and through Chrome 156.0.8078.76, headless, with Playwright's page.pdf(), A4, the same margins and backgrounds on. Our API's engine (2026.4) runs Chrome 153; every feature in the test is far older than either version.

The controls matter: wkhtmltopdf is not broken for the HTML it was built for. A template written years ago with -webkit-box, floats and ES5 scripts still renders. What fails is CSS and JavaScript written in the last decade, which is what designers, frameworks and code generators produce today.

What breaks in a real template

• The layout collapses. Logo and invoice title no longer share a line; sender, recipient and the four invoice details are stacked instead of side by side.
• Every colour from a variable is gone. The brand line under the header, the coloured title and the table header's background disappear. The header text is white, so the column titles become invisible.
• The font changes. The WOFF2 file is ignored, and the whole invoice falls back to Georgia.
• Script output is missing. The due date stays empty because the script uses const, which the engine cannot parse.
• Everything is a little smaller. wkhtmltopdf's default "smart shrinking" scales the page; we kept the default, as most installations do.

Chrome rendered the invoice as designed and repeated the table header at the top of page 2.

The alternatives compared

Which replacement fits depends on whether your HTML needs JavaScript and where the PDFs may be generated.

Prince and WeasyPrint lay out pages better than browsers in some print details, such as footnotes or running headers built in CSS, but neither runs a modern JavaScript engine. If your templates use charts or client-side formatting, a Chrome-based option is the safer migration. Moving to self-hosted Chrome means operating the browser yourself: updates every few weeks, fonts, memory and stuck processes. A hosted API moves that work to the provider. Dynamic Document API's free plan includes 50 renders a month without a credit card; paid plans start at €15 a month, billed annually. In our render-time benchmark a one-page invoice took a median of 124 ms in the renderer.

From wkhtmltopdf options to API parameters

Most wkhtmltopdf command lines translate one to one. The left column is the wkhtmltopdf option; the right column is the field in Dynamic Document API's pdf object, or the request field named.

Three things have no direct counterpart: the generated table of contents page (toc; use outline for PDF bookmarks or build the list in your HTML), the [section] and [subsection] placeholders, and --dpi, which Chrome does not need for vector output. All options: PDF options and headers and footers.

Before and after: the code

From the command line

Before, with wkhtmltopdf:

wkhtmltopdf --page-size A4 -T 20mm -B 20mm --print-media-type \
  --footer-center "Page [page] of [topage]" \
  invoice.html invoice.pdf

After, with Dynamic Document API. jq wraps the HTML file in the JSON request; print media is the default, so it needs no option:

jq -n --rawfile html invoice.html '{
  html: $html,
  pdf: {
    paper:  { size: "A4" },
    margin: { top: "20mm", bottom: "20mm" },
    footer: { enabled: true, center: "Page {{page}} of {{pages}}" }
  },
  delivery: "binary"
}' | curl https://api.dynamicdocumentapi.com/v1/pdf/from-html \
  -H "Authorization: Bearer $DYNAMIC_DOCUMENT_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- --output invoice.pdf

From Python (pdfkit)

Before:

import pdfkit

pdfkit.from_file("invoice.html", "invoice.pdf",
                 options={"page-size": "A4", "margin-top": "20mm", "margin-bottom": "20mm"})

After, with requests:

import os
import requests

with open("invoice.html", encoding="utf-8") as f:
    html = f.read()

res = requests.post(
    "https://api.dynamicdocumentapi.com/v1/pdf/from-html",
    headers={"Authorization": f"Bearer {os.environ['DYNAMIC_DOCUMENT_API_KEY']}"},
    json={
        "html": html,
        "pdf": {"paper": {"size": "A4"}, "margin": {"top": "20mm", "bottom": "20mm"}},
        "delivery": "binary",
    },
    timeout=60,
)
res.raise_for_status()
with open("invoice.pdf", "wb") as f:
    f.write(res.content)

One difference to plan for: wkhtmltopdf reads images and stylesheets from your disk, an API cannot. Put the CSS in the HTML, embed small images as data URIs, and link larger ones by HTTPS URL. If you render the same layout again and again, store it once as a template and send only the data.

pdfkit, Snappy, wicked_pdf and other wrappers

Many projects never call wkhtmltopdf directly. They use a library that does:

• Python: pdfkit
• Ruby: PDFKit and wicked_pdf
• PHP: KnpLabs Snappy and laravel-snappy
• .NET: DinkToPdf and Rotativa
• Node.js: the wkhtmltopdf package

Some of these libraries are still updated, but all of them run the same archived engine underneath, so they share every result in the test above. Switching from one wrapper to another changes nothing. Replace the renderer: the request in the previous section works from any language that can send an HTTPS request, and our SDKs and integrations wrap it for you.

If you have to keep wkhtmltopdf for now

Migrations take time. Until yours is done, limit the risk:

• Render only HTML you control. Never pass user-supplied HTML, Markdown converted to HTML, or third-party URLs to wkhtmltopdf.
• Keep local file access off. If you need --enable-local-file-access, allow only one directory with --allow.
• Isolate the process. Run it in a container without access to your internal network, so the request forgery in CVE-2022-35583 has nothing to reach. The project's status page also suggests AppArmor or SELinux.
• Write for the old engine. Use display: -webkit-box or floats instead of flexbox and grid, plain colours instead of variables, ES5 scripts, and fonts installed on the machine.

Questions

Test files and citation

• Test files, script and results (ZIP): both HTML files, the Chrome script, the commands and the four PDFs
• Feature test as PDF: wkhtmltopdf, Chrome
• Invoice as PDF: wkhtmltopdf, Chrome
• This page as Markdown, for language models and your own notes

The test files and results are licensed under CC BY 4.0: use them in your own articles, migration guides and slides, as long as you name Dynamic Document API and link to this page. A suggested citation:

Dynamic Document API (2026). wkhtmltopdf vs. Chrome: HTML-to-PDF test, November 2026. https://dynamicdocumentapi.com/alternatives/wkhtmltopdf/

Found a mistake, or a feature you would like to see tested? Write to support@dynamicdocumentapi.com.