wkhtmltopdf alternative for modern HTML to PDF

wkhtmltopdf helped define server-side HTML to PDF, but it is now archived and frozen on an old Qt WebKit engine. pdfkitt gives you a managed Chromium renderer behind one API call, so modern CSS layouts render the way they do in the browser.

The problem: archived code and a 2012 WebKit engine

The wkhtmltopdf GitHub repository has been archived and read-only since January 2023. That means production teams depending on it are carrying an abandoned binary into new document workflows.

The deeper issue is the renderer. wkhtmltopdf uses Qt WebKit, and its own project status notes that the WebKit inside Qt 4 has not been updated since 2012. For simple legacy templates that may be acceptable. For current product UIs, invoice templates, dashboards, and reports, that engine is far behind the CSS developers write today.

Modern CSS is where wkhtmltopdf falls apart

Most HTML templates today rely on display: flex, CSS Grid, media queries, modern spacing, and CSS3 features. wkhtmltopdf often ignores those rules or renders them as older block layouts, so columns collapse, cards stack incorrectly, and carefully designed documents drift between web preview and PDF output.

pdfkitt uses Chromium through Playwright, so the same layout primitives you use in the browser also work in generated PDFs. Flexbox behaves like Flexbox. Grid behaves like Grid. Modern CSS does not need to be rewritten into table-era markup just to make a PDF renderer happy.

Side-by-side comparison

	wkhtmltopdf	pdfkitt API
Maintenance	Archived on GitHub since January 2023 and now read-only	Managed service with maintained rendering infrastructure
Rendering engine	Qt WebKit engine whose WebKit has not been updated since 2012	Current Chromium via Playwright
Modern CSS	Flexbox, CSS Grid, and modern CSS3 often fail or render incorrectly	Renders browser-grade Flexbox, Grid, CSS3, web fonts, and print styles
Operations	You ship, patch, monitor, and debug the binary yourself	One hosted API call with quotas, rate limits, and infrastructure handled
Migration path	Command-line binary tied to legacy layout assumptions	Drop-in HTTP API: send HTML, receive a PDF

A drop-in managed API replacement

Instead of installing an abandoned binary, tuning flags, and debugging CSS regressions inside a legacy engine, send your rendered HTML to pdfkitt and receive a PDF response. Your application keeps ownership of the template; pdfkitt handles Chromium, pooling, rendering, and delivery.

The migration is intentionally small: replace the wkhtmltopdf command with a POST request to https://api.pdfkitt.dev/v1/convert. No SDK is required.

Quick start

Use the same curl, Node.js, or Python snippets from the pdfkitt dashboard. Swap in your API key, send HTML, and write the PDF response to a file.

Try it now — run this in your terminal (30 seconds)

No setup needed. Just paste this command and you'll get a real PDF back.

curl https://api.pdfkitt.dev/v1/convert \
  -H "Authorization: Bearer pdfk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"html":"<h1>Hello, world!</h1>"}' \
  --output document.pdf

When wkhtmltopdf still makes sense

wkhtmltopdf can still be reasonable for trusted, offline, legacy templates that already render correctly and do not need modern CSS. If you have a one-off internal script and the output is already acceptable, you may not need to move it.

But if your documents use Flexbox, Grid, modern CSS3, or user-facing layouts that must match a browser preview, an archived WebKit renderer is the wrong foundation. A managed Chromium API is a cleaner production path.

Try pdfkitt free - 1,000 PDFs/month, no credit card

Get an API key and replace your first wkhtmltopdf render in minutes.

Get started free Read the docs