Convert HTML to PDF

Less than people expect. An HTML document is the structure and the words: headings, paragraphs, tables, and references to everything else. The stylesheet that makes it look like anything is usually a separate file, named by address. So are the fonts, the images and the scripts.

When you open such a file in a browser, the browser fetches all of those and assembles the page in front of you — which is why it looks complete and why the file feels like it contains a web page. It does not. Hand the same file to anything that cannot fetch, and what remains is the text, in the browser’s default font, in one column.

It would be technically possible to follow those links and download the stylesheet, the fonts and the images. We do not, and the reason is worth stating plainly: a converter that fetches URLs found inside user files is a machine that will happily be pointed at internal addresses by anyone who works out that it fetches.

The conversion server here has no route to the internet at all. That is the same property that guarantees your document cannot be sent anywhere, and it necessarily means a linked stylesheet is a link to nothing. The two are the same decision seen from different sides.

Self-contained is the whole requirement. Put the CSS in a `<style>` block inside the document rather than linking it. Embed images as data URIs — base64 inside the `src` attribute — instead of pointing at files. Use fonts that exist on an ordinary system, because a webfont fetched from a font service will not arrive.

A great many generated documents already work this way: invoices from accounting software, reports from analytics tools, exports from note-taking apps and most HTML email templates are built self-contained precisely so they survive being moved around. Those convert with their layout intact. A page saved with "Save page as…" from a browser almost never does, because that produces an HTML file plus a folder of assets beside it.

If the goal is to keep a copy of a page you are looking at — an article, a receipt, a booking confirmation, a page that might disappear — close this tab and press Ctrl+P, or Cmd+P on a Mac, then choose "Save as PDF".

The browser has already done the hard part. Every stylesheet is loaded, every font resolved, every image fetched, every script run. It is producing a PDF from the finished page rather than from a file that describes one, and no external converter can match that because no external converter has the assembled page. This page exists for the HTML files you hold; for the pages you are viewing, the better tool is already open.

The document is set on standard pages with the converter's default typography unless the file carries styles of its own. There is no viewport to respond to, so a layout built for a screen is being asked a question it was not designed to answer.

A @media print block is not the lever it looks like. The HTML importer reads a narrow subset of CSS1 in which @page is recognised and @media is not, so the rules inside a print block are skipped with the block and the document is set from the ordinary styles instead. Put page size and margins in an @page rule, which does reach the output. Anything relying on JavaScript to arrange itself is gone for a simpler reason: nothing runs.

Text links are preserved as links in the PDF, so a URL in the document stays clickable. Internal anchors pointing at other parts of the same document work as well.

Links to files that were sitting beside the HTML will point at addresses that no longer resolve. That is not a fault in the conversion; it is what happens when a document that depended on its neighbours is moved on its own.

A screen scrolls sideways and a page does not, so a wide table has to be dealt with somehow. Columns compress, and past a certain width the text becomes too small to read while the table stays technically complete.

If the document is mostly a wide table, decide before converting rather than after: reduce the columns, or set a landscape page size in the CSS, which the conversion will honour.

These are the files that convert best, and it is not an accident. Invoices from accounting software, analytics reports, exports from note-taking apps and most HTML email templates are built self-contained so that they survive being forwarded.

Everything they need is inside the single file, which is precisely the property this conversion requires. If your HTML came from one of those, expect it to look right.

Nothing in the file is executed. A page that builds its content with JavaScript converts to whatever the markup says before the script would have run, which is frequently very little.

That is a safety property rather than a limitation to work around: running code found inside somebody's uploaded file is not a thing worth doing to rescue a layout. If the content only exists after a script has run, print from your browser instead.