Printing is a rendering mode, not an afterthought
Browsers have always been able to turn a page into paper, and for the last decade they have been able to turn it into a PDF instead. The engine doing that is the same one that lays out the page on screen, which is why the output is a proper document: real text, embedded fonts, selectable and searchable.
So converting HTML to PDF is not really a conversion. It is asking the browser to lay the markup out for a page-shaped medium rather than a screen-shaped one, and then saving what it produces.
The [msm_tool slug="html-to-pdf"] takes markup you paste, renders it in a new tab and opens the print dialogue. Choosing Save as PDF as the destination writes the file. Nothing is uploaded; it never leaves your browser.
What paste actually gets you
The markup is rendered with a plain sans-serif base and nothing else, which is the important thing to understand before pasting a page from a live site.
External stylesheets do not come. A fragment lifted from a styled site arrives unstyled, because the CSS that made it look like anything lives in a file you did not paste. The same goes for images referenced by relative paths, web fonts, and anything a script was going to build after load.
What does work: a self-contained fragment. Inline styles, or a <style> block pasted alongside your markup, are honoured. Absolute image URLs load. Tables, lists and headings render properly as themselves, which is the main reason to reach for HTML here rather than plain text — a real table stays a real table.
Two settings in the dialogue
Headers and footers off. Otherwise the browser stamps the page title, the URL, the date and a page number on every sheet.
Background graphics on, if your markup uses them. This one is off by default, which is why a document with coloured table rows, tinted panels or a dark header prints as plain white and looks broken. It is the single most common surprise in browser-generated PDFs.
Paper size and margins are worth a glance too, particularly if the document is going somewhere that uses different paper from you.
Writing markup for paper
Screen layout assumptions stop being true on a page, and a few habits avoid most of the damage.
- Avoid fixed pixel widths. A container set to 1200 pixels does not fit a page and gets scaled or clipped. Let content flow.
- Set sizes in points for print. Paper has real physical dimensions in a way a screen does not.
- Assume no colour. Much of what is printed goes through a black-and-white machine, and pale grey text on white becomes invisible.
- Links need their addresses. A clickable "read more" means nothing on paper. Spell the URL out, or accept that the link is decorative.
The print stylesheet you can use
CSS has real page-control rules, and a <style> block pasted with your markup can use them. page-break-before and page-break-after force a break at a chosen element, which is how you keep each section starting on a fresh page. page-break-inside: avoid keeps a table or a figure from splitting across two pages.
Wrapping those rules in @media print is the tidy way to do it, though when the markup exists only to be printed, applying them directly is simpler. Either way, this is the answer to the commonest complaint about browser-made PDFs — that page breaks land badly. They land where you did not tell them not to.
When to reach for something else
This route suits a self-contained fragment: an invoice, a table of data, a formatted letter, a report section. It is quick, it is private, and the output is a genuine text-based PDF.
It does not suit generating documents at scale or on a server, where a headless browser driven by a script is the standard approach and gives repeatable output. It does not suit rendering a whole live web page, where saving the page from the browser itself keeps the stylesheets. And it does not suit anything needing precise typographic control, which is what a typesetting system is for.
Read the preview before saving
The preview panel shows the real pagination. Look for a table cut across a break, a heading stranded at the foot of a page, and any element that came out unstyled because its CSS stayed behind. All three are fixable in the markup, and all three are far cheaper to fix now than after the document has gone out.