HTML is the world's most popular document format and PDF is the world's most popular finished document format, and the road between them is full of tools that quietly do the wrong job. Some snapshot a webpage's pixels. Some re-typeset its content. Some require your invoice to make a round trip through a server in another country. Which one you want depends on a single question: do you need the page's appearance, or its content?
| Method | What it does | Best for | Weakness |
|---|---|---|---|
| Browser Print → Save as PDF | Uses the real layout engine, prints the result | Archiving one page as it appears | Bakes in ads, banners, responsive quirks; not repeatable |
| Headless renderer (Playwright, wkhtmltopdf) | Runs a real browser on a server, scriptable | Devs generating thousands of docs | Needs a server; overkill for one invoice |
| In-browser typesetter | Maps HTML structure to PDF typography locally | Articles, tables, invoices, reports | No CSS layout engine — structure, not pixels |
Our HTML to PDF converter is the third kind. It chains two open-source libraries — html-to-pdfmake translates your markup into pdfmake's layout model, and pdfmake writes the actual PDF bytes, both in your browser tab. Nothing uploads, nothing queues, and the output is identical every time you run it.
A webpage's appearance is computed, not described. The HTML says "here's a div"; the CSS says "make it a flex row with 12-px gaps"; the browser's layout engine resolves all of that against the viewport, the installed fonts, and a few hundred interactions between rules. Any converter that isn't running a full browser is choosing an approximation.
Clean-print converters pick a different contract: your document's meaning converts — headings arrive as headings, tables as tables with their columns intact, links as clickable annotations — and the presentation comes from the PDF's own typographic settings. For invoices, receipts, documentation, and reports, that's actually the better deal: the output looks like a document, not like a screenshot of a webpage.
PDFs measure in points: 1 pt = 1/72 inch. Pages have fixed sizes, and every layout decision flows from them:
Screens think in pixels (96 per inch), so one CSS pixel is exactly 0.75 pt. That's why a 16 px body font — comfortable on screen — becomes 12 pt on paper, and why text tuned for a 1440-px monitor needs deliberate re-sizing for a 532-pt column.
Where this style of converter earns its keep is templated output. Say your app generates an invoice as HTML — a heading, a party block, a line-item table, totals. Paste it in, choose Letter portrait, convert: the table auto-sizes across the 532 pt column, the numbers right-align if the HTML says so, and the client gets a PDF that looks like an invoice instead of a printout with a URL in the footer. Thirty rows fit comfortably on the first page; the overflow rows break cleanly onto page two with the table structure preserved.
The same chain handles the neighboring jobs: a contract produced in Word converts through our Word to PDF tool (it runs .docx through mammoth into this very engine), and once the PDF exists, Sign PDF puts a drawn signature on it. Markdown authors can go Markdown to HTML first, then straight into this converter.
Paste markup, pick a page size and font, download a typeset PDF. The whole pipeline runs in your browser.
Open HTML to PDF →Use browser print when you want a memory of a page — its exact layout, its design, its moment in time. Use a headless renderer when you're a developer shipping product: PDF generation behind your own API, with real CSS, at scale. Use an in-browser typesetter for everything between: documents whose content is the point, generated or pasted, that deserve clean paper treatment without a server seeing them.
Match the tool to the contract. Appearance → browser or headless. Content → a typesetter. And whichever you choose, prefer the one where the conversion happens on your machine; the document you're converting usually has a reason to exist, and that reason rarely includes a third-party upload.
Fastest path: open the HTML in a browser and Print → Save as PDF — free and built in. For repeatable, styled output — invoices, reports, receipts — use a converter that typesets the HTML itself, either an in-browser tool like ToolAspect's (paste markup, set page size, download) or, if you're a developer generating thousands of documents, a headless renderer like Playwright or wkhtmltopdf on your own server.
Because a webpage's look comes from a layout engine — the multi-million-line component of a browser that computes CSS cascade, flexbox, positioning, and fonts. A converter that isn't a full browser maps HTML structure to PDF typography instead: headings, tables, lists, and links carry over; CSS layout does not. The exceptions are browser print (it uses the real engine) and headless Chrome (it is the real engine).
US Letter (612×792 pt, 8.5×11 in) for North American business documents; A4 (595.28×841.89 pt, 210×297 mm) everywhere else; US Legal (612×1008 pt) for contracts and court forms. Wide tables often read better in landscape — A4 landscape gives an 841.89 pt column, about 38% more line length than portrait Letter's 612 pt.
Yes — browser print and in-browser converters both run entirely on your machine. The general-purpose upload converters will take anything, which makes them the wrong choice for unreleased content, client invoices, or internal reports. An in-browser converter that typesets with JavaScript gives you the repeatability of a converter with the privacy of a local tool.