Markdown to PDF

1. Paste your markdown into the editor on the home page and press Share. You get a link to a rendered page.
2. Open that link and press Cmd+P on a Mac or Ctrl+P elsewhere.
3. Set the destination to Save as PDF and save.

The printed version drops the header, footer and every button, and uses the light palette regardless of which theme you are viewing in — a dark page prints grey text on grey and consumes a startling amount of ink.

Background graphicsis the one worth knowing about. In Chrome it lives under “More settings” and is off by default. Leaving it off is what this stylesheet assumes: code blocks print as text on white. Turn it on and each block gets a grey panel behind it, which some people prefer and which uses considerably more ink.

Margins at the default are fine. If a wide table is clipping, switching margins to Minimum usually recovers the last column.

Chrome and Safari differ on keeping blocks whole. Chrome respects the rule that stops a code block splitting across two pages; Safari applies it less consistently, so a block breaking mid-listing in Safari is a browser limitation rather than a formatting mistake.

Syntax highlighting is preserved — the same Shiki colours you see on screen, so code stays readable rather than becoming a wall of black monospace. Tables keep their borders and alignment, maths rendered with KaTeX prints as maths, and Mermaid diagrams print as vector graphics, so they stay sharp at any zoom rather than pixelating.

Long lines inside code blocks wrap instead of being cut off at the right edge. On screen those blocks scroll sideways; on paper there is nowhere to scroll to, so anything past the margin would simply be lost.

Links keep their text but lose their destination. A printed link shows the words it was attached to and nothing about where it pointed. This is a real limitation and worth knowing before you send a PDF to someone who might want to follow a reference.

Very wide tables can still clip. Tables are set to fit the page width, but a table with a dozen columns has to put something somewhere. Reducing the margins helps; splitting it into two tables helps more.

Images are printed at their natural size up to the page width. A very tall image may land on a page of its own rather than splitting.

Use headings properly. They are what stops a section title being stranded at the foot of a page with its content overleaf, and they give a reader something to navigate by once the document is static.

Prefer fenced code blocks with a language over indented ones — only the fenced form is highlighted, and colour does a lot of work on paper where there is no scrolling or searching.

Keep tables narrow enough to read. A table that needs horizontal scrolling on screen is a table that will fight the page. Two readable tables beat one clipped one.

If a document is genuinely long, remember the paste limit is 100,000 characters — which for English is roughly 98KB, and considerably more for scripts that need more bytes per character.