Wkhtmltopdf Alternative: What to Run Now the Project Is Dead

Three dates tell the story. June 2020: version 0.12.6, the final release. January 2023: the maintainers archive the GitHub repository and state plainly that the project is no longer maintained. Since then: nothing, including no patch for CVE-2022-35583, a server side request forgery hole rated 9.8 out of 10. If your service renders HTML that users influence, that vulnerability lets a crafted page make requests from inside your network. There is no version you can upgrade to that fixes it.

The engine problem is older than the abandonment. wkhtmltopdf wraps a Qt WebKit build whose CSS support froze years before the project did: no CSS grid at all, flexbox that half works, and page break handling that slices table rows in two. Every stylesheet your team writes today is written for browsers that left that engine behind a decade ago, so the gap between what designers build and what the PDF shows only widens. We wrote up the whole self hosting math in library versus API if you want the long version.

Most production wkhtmltopdf does not say wkhtmltopdf anywhere in the application code. It says pdfkit in a Python requirements file, wicked_pdf in a Rails Gemfile, laravel-snappy in a composer.json, or DinkToPdf in a .NET project. All of them are thin wrappers that shell out to the same archived binary, usually installed by a Dockerfile line nobody has read since 2021.

The quick audit: search your images for the binary itself. grep -r wkhtmltopdf Dockerfile* in your repos, or which wkhtmltopdf on a production host. If it is there, the January 2023 archive notice and the unpatched SSRF apply to you, whatever the wrapper is called.

Python: if your templates are static HTML and CSS, WeasyPrint is the healthy choice: actively maintained, pure Python, and genuinely good at print CSS such as page breaks and running headers. If your pages need JavaScript to finish rendering, WeasyPrint sees an empty shell and you want Playwright instead. Our Python HTML to PDF guide walks every option with code.

Node: you are one dependency away from Puppeteer or Playwright anyway; the question is not the library but whether you want to operate the browser fleet behind it. That math is in the Puppeteer alternative breakdown.

PHP, Ruby and C#: there is no healthy native engine. Dompdf renders pure PHP but skips JavaScript and chokes on modern CSS; DinkToPdf is the dead binary again. Realistic options are a Gotenberg container next to your app, a headless browser via Playwright bindings, or a rendering API.

Print typography: if your documents need running headers, page counters and widow control, that is PrinceXML territory, and we would rather point you at our honest DocRaptor comparison than pretend Chromium does typesetting.

Moving from frozen WebKit to modern Chromium is mostly an upgrade, but four things bite. First, CSS written around the old engine's bugs: vendor prefixed flexbox, table based layout hacks, zoom factors tuned to its odd DPI handling. They render differently, sometimes better, always differently. Second, page breaks: page-break-inside: avoid and friends behave more correctly in Chromium, which can shift pagination on long documents. Third, header and footer flags: wkhtmltopdf's --header-html and --footer-center options map to header and footer templates in modern engines, not one to one flags. Fourth, fonts: the new renderer resolves fonts differently, so anything not explicitly loaded as a web font may swap.

The test that catches all four: pick ten real documents from production, render each through the old and new pipeline, and put the pairs side by side. An afternoon of diffing beats a month of support tickets.

Every self hosted replacement above still leaves you operating something: a Python dependency chain, a browser fleet, a Docker container. The alternative is to make rendering someone else's pager duty. One call to Sitepdf sends a URL or raw HTML and returns a pixel perfect PDF from managed Chromium, with wait_for holding the render until your content is actually on screen.

And because the reason many wkhtmltopdf deployments exist is records, invoices, statements, confirmations, the same call can store a timestamped, retrievable snapshot of what was rendered: add archive=true and the dated record is kept under your account. The PDF generator API page covers generating from templates, and URL to PDF covers live pages.