By PDFKits Team — Published February 19, 2026
TL;DR: To convert HTML to PDF, match the method to the job: browser print (Ctrl+P) for one-off saves, PDFKits' in-browser Create PDF for files and pages you cannot upload, headless Chrome (Puppeteer/Playwright) for production pipelines, and WeasyPrint or wkhtmltopdf for constrained servers. Fidelity depends on the rendering engine — Chromium-based paths reproduce modern CSS exactly. PDFKits converts free and locally; Adobe Acrobat's online converter costs $14.99/month and uploads your file.
HTML-to-PDF looks trivial and turns out to hinge on one question: which engine draws the page? A Chromium-based path (your browser, headless Chrome) renders flexbox, CSS Grid, web fonts, and JavaScript-generated content exactly as Chrome displays them — webpage to pdf high fidelity comes free because the converter is the browser. Lighter engines (wkhtmltopdf's old WebKit, WeasyPrint's own layout engine) trade CSS coverage for speed, predictability, and a smaller footprint.
The second question is where rendering runs. Cloud converters like Smallpdf and Adobe Acrobat Online receive your HTML on their servers — fine for a public page, wrong for an invoice template full of customer data. PDFKits' Create PDF renders in your own browser, so a saved HTML file containing client information becomes a portable PDF without ever crossing the network. Knowledge workers saving an article, developers shipping 2,000 invoices a month, and ops teams printing shipping labels are solving three different problems; this guide maps each to its tool.
Best for: anyone whose output ranges from a single saved article to thousands of generated documents a day — the right tool changes with the volume.
| Feature | PDFKits | Adobe Acrobat Online | Smallpdf | iLovePDF |
|---|---|---|---|---|
| Cost | Free | $14.99/month | $9/month | $48/year Premium |
| HTML stays on your device | Yes | No — cloud | No — cloud | No — cloud |
| Modern CSS (Grid, web fonts) | Yes — browser engine | Yes | Yes | Partial |
| Convert saved/local HTML files | Yes | Limited | Limited | Limited |
| Authenticated pages | Yes, via saved file | No | No | No |
| Header/footer with URL + date | Yes | Yes | Limited | Limited |
For pipelines, none of these is the answer: a Puppeteer script on your own infrastructure converts a page in 1–3 seconds, scales to thousands of documents daily, and keeps data inside your perimeter. UI tools win below roughly twenty documents a day; scripts win above it.
Vanishing backgrounds. Print dialogs default to "no background graphics." Enable them, or pass printBackground: true in Puppeteer, or your colored callouts become white boxes.
Fonts that miss the snapshot. Rendering can start before @font-face files finish loading. Wait for document.fonts.ready in scripts; in the browser, pause a beat before printing.
Uncontrolled page breaks. Without break-inside: avoid on tables and figures, rows split mid-cell. The CSS Paged Media specification defines the @page rules — margins, page numbers, named pages — that turn web layouts into proper documents; WeasyPrint implements them most completely.
position: fixed surprises. Fixed elements repeat on every page in some engines and appear once in others. Test with multi-page content before shipping a template.
No print stylesheet. Twenty lines of @media print — hide navigation, expand collapsed sections, set readable font sizes — improve most conversions more than any tool switch.
Three usual suspects: the site ships @media print rules that restyle for printing, the dialog stripped background graphics, or web fonts had not loaded at snapshot time. Check each in that order — together they explain nearly every fidelity complaint.
Yes — be logged in and use browser print, or save the rendered HTML locally and convert the saved file. Programmatic pipelines pass session cookies to the headless browser before navigating.
Scroll to the bottom first so all content is in the DOM, or use the site's single-page or reader view. Scripts can trigger scrolling automatically before printing.
Only as good as the input HTML: semantic headings, alt text, and ARIA labels usually carry over as tags; untagged markup produces an untagged PDF. Full PDF/UA compliance needs post-processing in Acrobat Pro.
Yes, if they were loaded at conversion time. @font-face web fonts and local system fonts are embedded by Chromium-based converters, which is what makes the output portable.
A typical article lands between 200 KB and 2 MB; image-heavy pages can exceed 10 MB. Run the result through an optimizer if it will be emailed or hosted.
Not through a UI — write a Puppeteer or Playwright loop that visits each URL, waits for load, and saves with a sensible filename. Budget 1–3 seconds per page on average hardware.
Switch to the browser's reader mode before printing, or in a script extract the article container and convert that fragment. Both keep navigation chrome and ad slots out of the document.
Through Chromium-based converters, yes — SVG stays vector and scales cleanly. Older engines like wkhtmltopdf rasterize SVG and produce blurry output; if charts matter, stay on a Chrome path.
Not with PDFKits — the rendering and PDF assembly run client-side, and no request carries your content. Cloud converters necessarily receive the page or file on their servers.
Create PDF — convert URLs and HTML files locally. Merge PDF — combine converted pages with other documents. Optimize PDF — shrink heavy conversions for sharing. Page Numbers — consistent numbering across multi-page exports. Edit PDF — post-conversion touch-ups. Clean Metadata — strip URL and creator traces before distribution.