Inkspan › Guides › wkhtmltopdf

wkhtmltopdf alternatives in 2026: a benchmarked migration guide

Last updated 29 July 2026 · benchmarks re-run on each update · methodology

Every replacement for wkhtmltopdf makes a trade you should understand before you start rewriting templates. This guide measures four of them on the same document and tells you which fits — including the cases where the right answer is free software rather than a paid product.

Why you have to move

The question that decides your migration

wkhtmltopdf ran JavaScript. Qt WebKit was a real browser engine, so --javascript-delay and --window-status existed and people relied on them: charts drawn client-side, tables populated after load, templates waiting on a fetch. Half the replacement options cannot do this at all.

Run one test before choosing anything. Render this and read the output:

<p id="out">JS_DID_NOT_RUN</p>
<script>document.getElementById('out').textContent = 'JS_DID_RUN';</script>

The options, side by side

Benchmarks on the same document

Comparisons of these tools are usually prose. Here are numbers. One realistic A4 invoice — eight line items, CSS grid, flexbox, striped table, @page footer with page counters — rendered five times per path, median reported.

What the numbers actually say

• A warm Chromium beats everything. If your service keeps a browser process alive and reuses it, self-hosting is roughly an order of magnitude faster than any network call, and no API will close that gap. Long-running containers with steady traffic should self-host.
• Local WeasyPrint is ~4.8× faster than calling a hosted API — including one built on WeasyPrint — and costs nothing. If pip install weasyprint works on your platform and static HTML is enough, that is the answer. Anyone selling you an API should be willing to say so.
• Cold starts are where hosted wins. 871 ms beats a 1,499 ms cold Chromium launch. On bursty or serverless workloads you pay that launch on a large share of requests, and a warm remote renderer is genuinely faster than a cold local one.
• Chromium output was 2.5× larger on identical input. If you store or email documents at volume, file size compounds.

Flag-by-flag migration map

WeasyPrint, minimal version

from weasyprint import HTML

pdf = HTML(string=html, base_url="./assets/").write_pdf()

Playwright, minimal version

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(args=["--no-sandbox"])
    page = browser.new_page()
    page.set_content(html, wait_until="load")
    pdf = page.pdf(format="A4", print_background=True)
    browser.close()   # reuse the browser across requests in production

The real cost of self-hosting a browser

wkhtmltopdf shipped one binary. Every Chromium-based replacement ships an operations problem. This is not an argument against self-hosting — a warm Chromium was the fastest option we measured — but the costs are real and rarely listed:

• Size. The Playwright Chromium cache on our test machine measured 1,145 MB; a distro Chromium install measured 366 MB. AWS Lambda's unzipped limit is 250 MB, which is precisely why cut-down builds and Lambda layers exist.
• Fonts. Lambda runtimes ship with none. The common serverless Chromium build bundles Open Sans and nothing else, so anything outside Latin, Greek and Cyrillic renders as empty boxes until you ship a font layer and a fonts.conf.
• Version pinning. Serverless Chromium builds must match your Puppeteer version, and arm64 builds ship separately from x64. That is a compatibility matrix you now maintain forever.
• Tagged / accessible PDFs. Producing them from the standard serverless Chromium build requires recompiling Chromium with PDF accessibility flags enabled. If accessibility compliance is a requirement, price this in early.
• Memory and lifecycle. 512 MB is the floor, 1,600 MB+ the practical recommendation for acceptable cold starts. Pages that aren't closed leak; timeouts are the most common bug report in the ecosystem.
• Patching. You now own security updates for a web browser.

WeasyPrint avoids nearly all of this — no browser, no binary matrix — at the cost of no JavaScript. Its own friction is the Pango and cairo system libraries: unremarkable on Linux, genuinely annoying on Windows and in slim containers.

If you'd rather not run a renderer

A hosted API is the right call when rendering isn't your product, your traffic is bursty enough that cold starts dominate, or your platform makes the dependencies painful. Options worth comparing, and the two questions to ask each: what engine, and does it execute JavaScript?

The rest of the pipeline nobody mentions

Migration guides treat this as an HTML-to-PDF problem. Real wkhtmltopdf deployments rarely were. If yours also shells out to pdftk, qpdf, Ghostscript or wkhtmltoimage, those are separate migrations you haven't scoped — and pdftk has its own abandonment story.

Audit for these before you estimate the work:

• Merging generated documents into one file — statement runs, invoice batches
• Splitting a rendered PDF back into per-page files
• Compressing before storage or email
• Watermarking drafts, copies and confidential documents
• Rasterising pages to PNG for previews and thumbnails
• Filling AcroForm fields from structured data
• Extracting text and tables back out of PDFs you receive

You can assemble all of it from open-source parts — pypdf and qpdf cover most cases well. The reason to consider a single API is that each is a separate dependency, with separate system libraries and a separate migration the next time one gets archived. Inkspan exposes them as one authenticated POST each (/pdf/merge, /pdf/split, /pdf/compress, /pdf/watermark, /pdf/to-images, /pdf/fill-form, /extract/text, /extract/tables) — a convenience argument rather than a capability one. Both are legitimate reasons to buy; they are just different reasons.

A note on AI agents

One workload where the no-JavaScript trade-off costs nothing: documents generated by LLMs and agents. An agent producing an invoice, report or summary emits Markdown or server-side HTML. It is never rendering a single-page app, so a browser engine buys it nothing but latency and footprint.

For that shape of work the useful primitives are Markdown or template-plus-JSON to PDF, and extraction and translation on the way back in — not waitForSelector. If you are building document generation into an agent pipeline, evaluate on those, and don't pay for a browser you will never use.

Buying time: the maintained fork

If the migration is real work and you need a quarter to plan it properly, there is a middle option the other guides don't mention. newinnovations/wkhtml-packaging continues to publish wkhtmltopdf 0.12.6.1 builds for current distributions, including Debian 13 and Ubuntu 26.04, with releases as recent as May 2026.

That is a packaging fork, not a maintained engine: it does not modernise Qt WebKit and it does not fix the SSRF class. Use it to unblock a build, on trusted templates only, with a migration date on the calendar. It is a bridge, not a destination.

FAQ

Is wkhtmltopdf still safe to use on my own templates?

Lower risk than the CVSS 9.8 headline implies if you never render user-supplied HTML and block the renderer's outbound network access. It is still an unpatched engine dropped by Debian, so treat continued use as deliberately accepting debt with a deadline.

What is the closest drop-in replacement?

Chromium via Playwright or Puppeteer. It is the only common option that keeps JavaScript execution, which is the capability most likely to break silently.

Will my PDFs look the same afterwards?

No. Pagination changes on any engine you move to. Diff your busiest templates page by page and expect to adjust page-break CSS.

Is WeasyPrint good enough for invoices?

Yes, and arguably better suited than a browser. Paged media — margin boxes, page counters, running headers — is what it was built for. The constraint is JavaScript, which invoices rarely need.

Do I need a paid API at all?

Often not. If pip install weasyprint works on your platform and your HTML is static, use the library. Consider hosted when the dependencies are painful, cold starts dominate your traffic, or you want the operations to be someone else's problem.

Which is fastest?

A warm Chromium, by roughly an order of magnitude, provided you keep the process alive. On cold starts that reverses and a warm remote renderer wins.

Methodology

What was measured. One A4 invoice with eight line items, CSS grid, flexbox, a striped table and an @page footer using page counters. Five iterations per path, median reported, identical input HTML throughout. Chromium 150 driven by Playwright; WeasyPrint 65.1; hosted call to POST /v1/generate/html.

What these numbers do not prove. They come from a single Linux VM, not a controlled benchmark rig, and one document is not a representative corpus — heavy documents with many images or webfonts will shift the ordering. The hosted figure includes network round-trip from the test machine, so your latency depends on your distance from the API. The "cold process" row launches a fresh OS process per iteration as a stand-in for a serverless cold start; it is not a measurement of AWS Lambda. Treat all of it as an order-of-magnitude guide and re-run on your own documents before making a decision that matters.

Changelog

• 29 July 2026 — First publication. Benchmarks run against Chromium 150 and WeasyPrint 65.1; Debian Trixie removal and CVE status verified.

Related: generate a PDF from HTML in Python · template to PDF · invoice PDF API · merge PDF files