Markdown to PDF — what the renderer supports, what it doesn't, and why a small font set is the right trade-off
Markdown has become the lingua franca of technical writing. Every README, every internal wiki, every team's design-doc folder runs on it. Turning those markdown files into shareable PDFs is one of those operations that should be trivial but often isn't — the available tools either pull in heavy CSS engines, produce inconsistent output, or require accounts. Our free Markdown-to-PDF renderer is intentionally lean: a minimal inline parser, four standard PDF fonts, no font embedding, no server round-trip. Here is what that means for the output, the supported markdown syntax, and the two cases where the simpler approach beats the heavier ones.
How rendering works
The tool runs entirely in your browser. We parse the markdown locally with a minimal inline parser that handles the common syntax (headers, paragraphs, bold, italic, code, lists, blockquotes, links, horizontal rules). Each block is then drawn via pdf-lib onto an A4 page with 1-inch margins. New pages are added automatically when content overflows.
Fonts are PDF's four standard fonts: Helvetica for body, Helvetica-Bold for headings and bold runs, Helvetica-Oblique for italic, Courier for inline and block code. These are guaranteed to be present in every PDF reader without embedding, which keeps output files small (typically under 100 KB for a 5-page document) and rendering consistent across viewers.
What's supported
The full supported syntax list:
- Headers (# / ## / ###). Three header levels at distinct sizes. Sufficient for documentation, design docs, and READMEs; H4 and deeper collapse to H3 size to prevent visual noise.
- Paragraphs. Lines separated by blank lines become paragraphs. Single line breaks within a paragraph are honored as hard breaks.
- Bold (**bold**) and italic (*italic*). Both single-character and double-character runs work as expected. Combined (**_bold-italic_**) renders correctly.
- Inline code (`code`) and code blocks (```). Inline code gets Courier styling inline. Fenced code blocks become indented Courier paragraphs.
- Lists — unordered (-) and ordered (1.). Both list types with hanging-indent layout. Nested lists work up to 3 levels of indentation.
- Blockquotes (>). Indented with a left border line, classic blockquote style.
- Horizontal rules (---). Drawn as a thin horizontal line.
- Links ([text](url)). Rendered as blue text. Clickable hyperlink annotations are on the v2 roadmap; for now the URL is visible in the text but not click-through.
What's not supported (and what to use instead)
The renderer is intentionally focused. Three features we deliberately do not support, with the right tool for each:
- Tables (pipe-syntax). Markdown tables are surprisingly tricky to render in PDF (column-width calculation, header repetition, line wrapping inside cells). The right tool for tabular data is CSV-to-PDF, which has proper table layout. If your markdown contains a table, extract the rows + columns to CSV first.
- Images (). Embedding remote images requires fetching them at render time, which conflicts with the no-server-round-trip design. For documents with images, use AI Generate which composes documents with embedded images, or convert to HTML first then HTML-to-PDF.
- HTML passthrough. Many markdown renderers allow inline HTML for cases the markdown syntax doesn't cover. We render any inline HTML literally (it appears in the output as text). For documents that need HTML features, render through a heavier pipeline.
When the lean approach beats the heavy one
Cases where the minimal renderer is actually the right tool:
- Documentation PDFs for sharing. README.md → README.pdf to email to a stakeholder who doesn't use GitHub. The output is clean, small, and readable. No formatting surprises.
- Meeting notes archived to PDF. Quick conversion of running notes (in markdown) to a shareable PDF. The format is the same as the source; you don't lose information.
- Style-guide consistent output across documents. Because the renderer uses fixed fonts and styles, every document looks the same. Useful when consistency across a series of documents matters more than per-document customization.
- Privacy-sensitive content. Everything runs in your browser. Markdown containing internal information stays on your machine end-to-end.
- Offline use. Once the page loads, the tool works without network access. Useful for air-gapped or restricted environments.
Limits and compatibility
On the free web tool, markdown rendering handles inputs up to 5 MB of markdown source. Output is A4 with 1-inch margins; page size override is on the v2 roadmap. Auto-pagination handles documents of any length within the input cap. Output files typically run 50-200 KB depending on length.
Common pairings: Markdown-to-PDF → Add Page Numbers for final-deliverable polish. Markdown-to-PDF → Merge to combine multiple rendered docs into one bundle. For richer markdown features, use AI Rewrite with markdown-to-PDF instruction.