Every way to make a PDF,
and when to pick it.
Written to be useful rather than flattering. Several of these are free, and for a lot of documents they are the right answer. Each page says plainly when that is the case.
html4pdf vs Puppeteer
Run 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 wkhtmltopdf
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.
html4pdf vs WeasyPrint
If 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 Dompdf
Dompdf 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 html2canvas
jsPDF 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/renderer
Use 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 browser
If 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 Playwright
Playwright 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 Lambda
It 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 Gotenberg
Gotenberg 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 mPDF
mPDF 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 ReportLab
ReportLab 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 iText
If 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 QuestPDF
QuestPDF 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 PDFKit
PDFKit 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.
Choosing an approach
What is the best way to generate PDFs from HTML?
There are only three real approaches. Render in a browser, which is accurate but means running Chrome. Use a library with its own CSS engine, which is light but will disagree with your design. Or draw the document in code, which is exact and inflexible. Everything on this page is one of those three.
Should I use a PDF API or run my own renderer?
Volume decides it. Below a few thousand documents a month, running a browser costs more in attention than an API costs in money. Above that, your own renderer gets cheap, and the operational work is amortised over enough documents to be worth it.
Why do PDF libraries render my CSS incorrectly?
Because most of them are not browsers. Dompdf implements CSS 2.1, wkhtmltopdf froze before flexbox, WeasyPrint has its own engine with its own gaps. Only a browser-based renderer gives you what you saw on screen.
Is a free library good enough?
Very often, yes, and we say so on each page. If your document is a simple template without scripts, WeasyPrint in Python or mPDF in PHP will do the job for nothing.
What makes html4pdf different from other PDF APIs?
Nothing is stored. The document is rendered in memory and released with the response, so there is no bucket of your customers' invoices anywhere. Pricing is per document with no subscription, and credits do not expire.