html4pdf vs printing from the browser
Before adding a dependency, it is worth asking whether the browser already does this. Often it does, and the honest answer to the whole question is a stylesheet.
The short answer
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.
What the browser's print dialog is
Every browser can print to PDF, and window.print() opens that dialog from JavaScript. With a print stylesheet, @page rules for margins and page-break properties, the output is produced by the same engine that rendered the page, which makes it as accurate as it gets. It costs nothing and needs no library.
Side by side
| the browser's print dialog | html4pdf | |
|---|---|---|
| Accuracy | Perfect, it is the user's own browser | Headless Chrome, effectively the same |
| Cost | Free | From $0.033 per document |
| Who triggers it | The user, in the dialog | Your code, any time |
| Do you get the file | No, it is saved by the user | Yes, in the response |
| Email or archive it | No | Yes |
| Scheduled or bulk output | No | Yes |
| Headers and footers | Browser defaults the user can change | Controlled by you |
| Consistency | Varies by browser, OS and user settings | Same engine and settings every time |
Choose the browser's print dialog when
- A person is looking at the page and wants a copy of it.
- You want to ship today with a stylesheet and no backend.
- Nothing downstream needs the file.
- The content is sensitive enough that it should never be transmitted.
Choose html4pdf when
- The PDF is attached to an email, stored, or sent to someone else's system.
- It is generated by a job, a webhook or an invoice run with nobody watching.
- Every copy must be byte-for-byte consistent, not shaped by browser settings.
- You need the file on the server, where the user's browser cannot help you.
See the code
The working example, in the language this decision is being made in.
the browser's print dialog: common questions
Can JavaScript save a page as PDF without a library?
It can open the print dialog with window.print(), and the user chooses Save as PDF. Your code never receives the file: browsers do not expose it, for good reason.
How do I control margins and page breaks when printing?
With CSS: @page for size and margins, break-inside: avoid to keep a block together, and break-before to start a new page. A print stylesheet gets you most of the way.
Why does my printed page include a header with the URL?
That is the browser adding it, and the user can turn it off in the dialog. You cannot control it from the page, which is one of the reasons server rendering exists.
Is the output the same across browsers?
No. Margins, default headers and font handling differ by browser and operating system, so two users printing the same page get slightly different files.
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 wkhtmltopdfwkhtmltopdf 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 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 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.