Why convert HTML to PDF at all
HTML is the most flexible way to describe a page, which is why invoices, reports, receipts, statements and tickets are so often generated as HTML. But HTML is not a document. It reflows with the window, it depends on fonts and stylesheets that may not be available later, and it cannot be signed, numbered or filed.
PDF is the opposite: a fixed page with measured text positions, a page count, and the same appearance on every device. Converting between the two is what every billing system does, usually on a server. This tool does it in the browser instead, which is a genuine advantage when the HTML contains customer names, amounts or personal data.
It is also useful in the opposite direction from what you might expect: developers use it to turn code snippets, README files and API documentation into PDFs for review, and students use it to submit HTML assignments as printable documents.
What is supported, and what is not
Supported well: h1–h6 headings with proportional sizes, paragraphs, bold and italic, underlined text, ordered and unordered lists with markers, tables with header rows, blockquotes with a coloured bar, horizontal rules, pre and code blocks in a monospace font, links (rendered as underlined text, since a PDF viewer cannot follow them from inside the page), and line breaks.
Not supported, deliberately: CSS layout. Flexbox, grid, floats, absolute positioning and media queries have no meaning on a fixed page. If you need an exact visual replica of a complex styled page, the honest answer is to use the browser’s own print dialog and choose “Save as PDF” — it implements the full CSS specification because it is the same rendering engine.
Also not supported: external images. Fetching an image from a URL would require a network request through a server to avoid CORS problems, which contradicts the privacy design of this site. Images embedded as data: URIs are embedded normally; any other <img> is replaced by a short placeholder that names it.
Building a simple invoice template that converts cleanly
Start with an <h1> for the document title and a short paragraph with your company details, then a <hr>. Metadata such as invoice number and date belongs in a paragraph with bold labels. The line items go in a <table> whose first row uses <th> cells for the column headings — those are shaded automatically.
Keep columns to four or five. The converter divides the page width equally between cells, so a table with ten columns produces very narrow, hard-to-read content. Put the total in a bold paragraph after the table rather than in another table row, and use a blockquote for payment terms — it renders with a coloured left bar that draws the eye.
If the invoice is long, page numbers appear automatically at the bottom centre, which is what accountants expect. And because the text is real, the PDF can be searched for an invoice number later, which is not true of HTML converted through a screenshot-based service.
Code snippets, documentation and plain text
Wrapping code in <pre> gives it a light grey background, a monospace font and preserved whitespace, which is what makes code readable in a PDF. Individual lines may still wrap if they are very long, so keep the base text size small — 9 or 10 points — for wide code.
For escaping, remember that literal angle brackets must be written as < and >, and ampersands as &. If you would rather not escape anything, tick “Treat my input as plain text” and the converter will show the tags literally, converting line breaks to <br> for you. That is the quickest way to make a PDF out of a diff, a log file or a message that happens to contain angle brackets.
One practical tip for both: the base text size and page margin have a bigger effect on the final document than any other setting. Narrow margins with 9 point text fit roughly twice as much content per page, which is exactly what you want for documentation and exactly what you do not want for a client-facing invoice.