Markdown, turned
into a real PDF

The original 2004 implementation was a Perl script with an informal description, and it left many cases undefined. Different tools filled those gaps differently, which is why the same document can render three ways in three places.

CommonMark exists to pin down the ambiguous cases, and GitHub Flavored Markdown builds on it with tables, strikethrough, task lists, and automatic linking. Most tools you meet today implement one or the other.

Markdown describes structure, while PDF describes a fixed page. Converting means making layout decisions the source document never specified: page size, margins, where text breaks across pages, and how wide a table is allowed to be.

Structural elements translate cleanly. Headings, paragraphs, ordered and unordered lists, blockquotes, bold and italic, links, and fenced code blocks all have direct print equivalents.

What translates poorly is anything that assumed a resizable viewport. A wide table cannot reflow to fit a fixed page, so it either shrinks or overflows. Very long unbroken strings such as URLs or minified code have no break opportunity and can run past the margin.

Markdown has no page break syntax, because it was never designed with pages in mind. Converters decide where breaks fall based on the content flowing down the page.

The practical lever is structure. Breaking a long document into sections with clear headings gives the converter natural places to break, and keeps a heading from being stranded at the foot of a page with its content overleaf.

If you need precise pagination, generate the PDF first and adjust the source, rather than expecting the Markdown to encode exact layout. For documents where pagination genuinely matters, a typesetting system such as LaTeX is a better fit than Markdown.

PDF generators embed a specific set of fonts, and any character outside those fonts cannot be drawn. This surfaces most often with Chinese, Japanese, Korean, Arabic, Hebrew, and Devanagari text, which typically render as blank boxes rather than throwing an error.

Emoji have the same problem for the same reason, since they require a colour emoji font that standard PDF font sets do not include.

If your document is not primarily Latin script, check a short sample through the converter before committing to a long document. A tool with the right embedded fonts, or a conversion route that goes through a browser print engine, will handle it better.

Conversion happens entirely in your browser in three steps. The Markdown is parsed to HTML by marked, that HTML is sanitised with DOMPurify to strip anything unsafe, and the cleaned result is laid out into a PDF by pdfmake.

Nothing is uploaded. Your document never leaves the machine, which makes this a reasonable choice for drafts, internal notes, and anything you would not want to paste into a hosted service. It also means conversion speed depends on your device rather than on server load.

This tool suits documents that are mostly prose and structure: READMEs, meeting notes, specifications, documentation, and drafts you want to hand to someone as a fixed file.

It is the wrong tool for a few specific jobs. Documents needing exact typographic control, numbered figures, cross-references, or a bibliography are better served by LaTeX or Typst. Documents needing custom branding, headers, and footers on every page are better handled by a template-driven pipeline such as Pandoc with a custom template.

For a printable document that mainly needs to look like your website, printing the page to PDF from the browser with a dedicated print stylesheet is often simpler than any conversion step.