html4pdf vs wkhtmltopdf
For a decade wkhtmltopdf was the default answer in every language, usually through a wrapper: WickedPDF, pdfkit, DinkToPdf, Browsershot's predecessor. Then the web moved and it did not.
The short answer
wkhtmltopdf is still fine for simple documents you already have working. For anything new, or anything using modern CSS, its archived WebKit engine is the problem you will eventually hit.
What wkhtmltopdf is
wkhtmltopdf is a command line tool that renders HTML to PDF using an old fork of QtWebKit. It is a single binary, it needs no runtime, and it is genuinely fast. Development has stopped and the project is archived, so the rendering engine is frozen at a point in web history before flexbox and grid were usable.
Side by side
| wkhtmltopdf | html4pdf | |
|---|---|---|
| Rendering engine | A fork of QtWebKit, frozen | Current headless Chrome |
| Flexbox and grid | Not supported, layouts fall back to blocks | Supported |
| JavaScript | Old engine, unreliable for modern scripts | Full support, scripts run before capture |
| Web fonts | Patchy | Google Fonts and @font-face work |
| Maintenance | Archived, no security updates | Chrome, updated continuously |
| Installation | A native binary per platform, per architecture | None |
| Speed | Very fast, no browser to start | Three to five seconds including the round trip |
| Cost | Free | From $0.033 per document |
| Headers and footers | Built in, via command line flags | Via page options, or CSS |
Choose wkhtmltopdf when
- You have documents that already render correctly and nobody is redesigning them.
- You need sub-second rendering and your layout is plain CSS.
- The work must stay entirely offline, with no outbound network call.
- Cost per document has to be zero.
Choose html4pdf when
- Your design uses flexbox, grid, or a web font, and the PDF no longer matches the page.
- You are tired of shipping a platform-specific binary in your image.
- An archived dependency with no security updates is becoming a compliance conversation.
- You are starting something new and would rather not inherit the problem.
See the code
The working example, in the language this decision is being made in.
wkhtmltopdf: common questions
Is wkhtmltopdf deprecated?
The project is archived and no longer developed. It still runs, and many systems still depend on it, but there are no fixes coming, including security fixes in the bundled engine.
Why does flexbox not work in wkhtmltopdf?
Its engine is an old fork of QtWebKit that predates usable flexbox support. The properties are ignored, so the layout falls back to normal block flow, which is why a two column design arrives stacked.
What should I replace wkhtmltopdf with?
Something based on a current browser. Run it yourself with Puppeteer, Playwright or chromedp, or call an API that runs one. If your documents are simple and you want pure Python, WeasyPrint is also a reasonable landing spot.
Will my existing HTML work without changes?
Usually it will look better, because Chrome supports more than the old engine did. Watch for layouts that were built around wkhtmltopdf quirks, and for its command line header and footer flags, which become CSS or page options.
Try it before you decide
New accounts get 10 free credits, no card. Send the HTML you already have and compare the output against whatever you are using now.
Other comparisons
- html4pdf vs PuppeteerRun Puppeteer yourself if PDFs are high volume and you already operate containers. Use an API if PDFs are a feature of your product and you do not want Chrome in your deployment.
- html4pdf vs WeasyPrintIf your document is HTML and CSS with no scripts, WeasyPrint is excellent and free, and you should use it. If anything on the page is drawn by JavaScript, you need a browser.
- html4pdf vs DompdfDompdf is the right answer for a simple document on shared hosting with no extra services. It is the wrong answer for anything designed with modern CSS, because it implements CSS 2.1.
- html4pdf vs jsPDF and html2canvasjsPDF with html2canvas is free and needs no backend, and it produces a picture of your page rather than a document. If the text has to be selectable, searchable or printable at quality, it is the wrong tool.
- html4pdf vs @react-pdf/rendererUse react-pdf when the document is small, stable, and worth building as its own component tree. Use a renderer when the PDF should be the same thing your users already see on screen.
- html4pdf vs printing from the browserIf the user is the one who wants the PDF and is sitting in front of the page, use window.print() and a print stylesheet. If your system needs the file, you need a renderer.
- html4pdf vs PlaywrightPlaywright is the better browser automation library. It is not a better PDF pipeline, because the cost was never the library: it is operating the browser. Use it if you already run it, call an API if you do not.
- html4pdf vs running Chromium in a LambdaIt works, it is free, and it is the single most fiddly part of most codebases that do it. If your function is already near the size limit or your users wait on the first request, the trade has stopped paying.
- html4pdf vs GotenbergGotenberg is the right answer if you want this capability inside your own infrastructure and have somewhere to run a container. We are the right answer if you want it without running anything.
- html4pdf vs mPDFmPDF is the best free answer in PHP for long, table-heavy documents written as documents. It is still its own engine, so a design built in a browser will not arrive intact.
- html4pdf vs ReportLabReportLab is the right tool when the document is a fixed, precise artefact and you want no dependencies. It is the wrong tool when the design changes often, because every change is a code change.
- html4pdf vs iTextIf you need deep PDF manipulation on the JVM and can accept AGPL or buy a licence, iText is the strongest tool available. If you only need HTML turned into a document, the licence question is one you can skip entirely.
- html4pdf vs QuestPDFQuestPDF is excellent for documents you are happy to describe in C#. If the document already exists as a web page, you would be rebuilding it, and that duplication is the whole cost.
- html4pdf vs PDFKitPDFKit is a good fit for simple, fixed documents generated at volume, where no browser and no network is worth writing the layout by hand. Beyond that the hand-written layout becomes the problem.