Two ways to convert HTML, and only one of them keeps your text
Almost every free HTML-to-PDF tool works one of two ways, and the difference determines what you get.
The server approach uploads your file to a machine running headless Chrome, which renders it and sends a PDF back. Fidelity is excellent, it is a real browser. The cost is that your document went to someone else's computer. For a blog post that is nothing; for an invoice, a payslip, a contract or an exported bank statement, it is a decision worth making deliberately rather than by default.
The screenshot approach runs in your browser, draws the page onto a canvas, and wraps that picture in a PDF. Nothing is uploaded, which is good. But the output is a photograph of a document: you cannot select a line, search for a word, copy an amount, or click a link, and a screen reader finds nothing at all. It is also large, a five-page text document that should be 40 KB routinely comes out at 2 MB.
This tool takes a third route. It parses the HTML locally, lays it out into pages, and draws the text with real fonts. You get selectable, searchable text, working links and a small file, without anything leaving your machine. The trade is CSS fidelity, and the next section is honest about exactly where that line falls.
What comes through, and what does not
Rather than making vague claims about "supporting HTML", here is the actual list.
| Comes through | Does not |
|---|---|
| Headings h1–h6, sized by level | External stylesheets and CSS classes |
| Paragraphs, line breaks, horizontal rules | Colours, backgrounds and borders from CSS |
| Bold, italic, monospace, and combinations | Floats, grid, flexbox and absolute positioning |
| Ordered and unordered lists, nested, with correct numbering | Multi-column page layouts |
| Tables with headers, borders and sensible column widths | Anything drawn by JavaScript after load |
| Links, as real clickable annotations | Web fonts and non-Latin scripts |
| Blockquotes and preformatted code, indentation intact | Charts rendered to canvas or SVG |
| Embedded JPEG and PNG images | Images hosted on other domains |
Inline font-weight and font-style | Videos, forms and interactive elements |
page-break-before: always | Headers and footers defined in CSS |
If your document is text with structure, an invoice, a report, an export from a system, a saved article, documentation, a generated statement, the left column is the whole document and you will get an excellent result. If it is a designed marketing page whose appearance is the content, use your browser's Print → Save as PDF instead. That is a real browser rendering it, and no free web tool will beat it.
The details that usually go wrong
Converting HTML to a paged document is mostly a series of small decisions, and getting them wrong is what makes most converters' output look off. These are the ones this tool handles deliberately.
Long words do not run off the page. A URL, a hash, a long identifier, anything wider than the text column is broken across lines rather than disappearing into the margin.
Headings do not end up stranded. A heading that would fall at the very bottom of a page, with its text overleaf, is moved down to start the next page with its content.
Nested lists keep their structure. Sub-items are indented and get a different bullet, and a nested list is not swallowed into the text of the item containing it, a surprisingly common bug.
Ordered lists count properly, including a list starting at a number other than one.
Code keeps its indentation. Whitespace inside a pre block is the content, so it survives, and an over-long line is wrapped with its indentation carried onto the continuation.
Wide tables lose width where it hurts least. Every column keeps at least its longest word and the prose columns wrap, so a column of dates or amounts is not compressed to fit a column of prose, and the table never crosses the right margin. Merged cells span the columns they cover.
Hidden things stay hidden. Elements with display: none, a hidden attribute or aria-hidden are skipped, along with scripts, styles, navigation and forms, the page furniture nobody wants in a printed document.
Practical uses
Invoices and receipts from a system that only exports HTML. Common in older accounting and billing software. The table comes through as a table, and the total is still selectable text your accountant can copy.
Saving an article or documentation page for offline reading. Save the page from your browser, convert the file, and you have a searchable PDF a fraction of the size of a screenshot.
Turning generated reports into something to send. If a script or a tool produces HTML, pasting it into the box above gives you a paged document with page numbers.
Anything confidential. The whole reason this runs locally. If the answer to "would I email this to a stranger?" is no, it should not go to a conversion server either.
After converting
If the PDF needs to meet an upload limit, the PDF compressor will bring it down while keeping the text selectable, it detects that a document is text rather than a scan and refuses to flatten it into images. To combine the result with other documents, use merge PDFs, and if you are sending it onward, the metadata remover will strip the author and software fields first.