Markdown to PDF

The usual way to do this, and why this is easier

The established answer to "how do I turn Markdown into a PDF" is Pandoc plus a LaTeX distribution. It produces beautiful output and it is genuinely the right tool if you are publishing a book. It is also a multi-gigabyte install, a command line, and a template language, which is a lot of ceremony for turning a README, a set of meeting notes, a specification or an AI chat transcript into something you can email to someone.

The other common answer is to paste your Markdown into a website. That works, and it also means your text — which for the files people actually convert is often an internal spec, a draft contract, a set of interview notes or a conversation with a language model — is now on somebody else's server.

This does the conversion in the page you are reading. The Markdown is parsed into a structured document, and that document is typeset onto PDF pages by a layout engine running in this tab. There is no upload, no install and no account. What it does not try to be is a typesetting system: there are no templates, no citation processing, no maths rendering and no custom CSS. It produces a clean, readable document, which for the overwhelming majority of Markdown is exactly what was wanted.

What of Markdown is supported

The subset that has a meaning on a printed page. ATX headings from one to six hashes, and setext headings underlined with equals signs or dashes. Paragraphs, with lazy continuation — a hard-wrapped paragraph in the source is joined back into one flowing paragraph, which is what almost everyone wants and what a naive converter gets wrong.

Bold, italic, and inline code. Code spans are parsed before emphasis, so an asterisk inside backticks stays an asterisk. Underscores inside words do not create emphasis, so `snake_case_names` survive intact — a small thing that breaks constantly in weaker parsers and mangles any document about code.

Bulleted and numbered lists, nested by indentation to five levels, with the marker style following the nesting depth. Block quotes, including multi-line ones. Fenced code blocks with an optional language tag, drawn in a monospaced face on a shaded background that continues correctly across a page break. Thematic breaks. Pipe tables, with a header row that repeats on every page the table spans, and escaped pipes inside cells handled properly. Links, both inline and autolinks, kept as real clickable annotations in the PDF with the URL intact.

Not supported, and passed through as literal text rather than silently swallowed: raw HTML blocks, reference-style links, footnotes, definition lists, task-list checkboxes, and LaTeX maths. Images referenced by URL are not fetched, because fetching one would mean this page making a network request with your document's contents in it; their alt text is kept instead.

Making it look like a document rather than a print-out

A few of the controls make a disproportionate difference. Typeface first: Times for anything prose-heavy — a proposal, a report, an article — and Helvetica for documentation, notes and anything with a lot of code in it. The difference in how long a reader lasts on the page is larger than it sounds.

Text size and margin next. The default of 11 point with a 56 point margin gives a comfortable line length on A4, which is roughly 90 characters. If you push the text size up you should push the margin up with it; a long line of large type is genuinely harder to read than the same text set smaller.

Page numbers are on by default, which is worth keeping for anything longer than a couple of pages, and A5 is worth trying for a document meant to be read on a phone — it produces a page shape that fits a phone screen without zooming, which A4 never does.

What this is actually used for

Three uses come up constantly, and they shaped the defaults. The first is documentation: a README or a set of docs that has to go to someone who will not open a repository. The second is notes — meeting minutes, research notes, a specification drafted in a Markdown editor — that need to become a shareable artefact.

The third, and increasingly the most common, is output from a language model. Chat assistants produce Markdown, and a long answer full of headings, lists and tables is close to unreadable as a wall of raw asterisks and pipes when pasted into an email. Converting it produces something a colleague or client can actually read, and doing it locally means the conversation is not being handed to a third service on its way there.

Because the same parser feeds the Word writer, the sibling route is available too: if you need the file editable rather than final, the PDF to Word tool works in reverse from a PDF, and Markdown itself can be produced from any document this site converts.