Markdown is the best format to write in and the worst to hand to someone. A README, a set of meeting notes, a technical spec — all perfectly readable to you and full of hashes and asterisks to a client. Paste or upload your .md above and get a properly typeset PDF back.
Below: which flavour of Markdown actually gets rendered, why your images may not appear, and the handful of things a paginated document does that a web preview never has to worry about.
Markdown is not one specification. The original from 2004 covered headings, emphasis, lists, links, blockquotes and code. Everything beyond that was added later by different people in different directions, and support varies.
Reliable everywhere — headings with #, **bold** and *italic*, ordered and unordered lists, links and images, blockquotes with >, inline code with backticks, fenced code blocks, and horizontal rules.
GitHub Flavored Markdown added pipe tables, task lists with - [ ], strikethrough, and automatic linking of bare URLs. These are widely but not universally supported, and tables in particular are the ones most likely to render differently between tools.
Rarely supported anywhere — footnotes, definition lists, LaTeX maths between dollar signs, Mermaid diagrams in fenced blocks, and YAML front matter. Front matter is worth knowing about: those --- delimited metadata lines at the top of a file are a static-site-generator convention, not Markdown, so they often appear as literal text at the top of your PDF. Delete them before converting.
The reliable test is to convert one page and look at it rather than assume.
Markdown references images rather than containing them.  is an instruction to fetch a separate file, so what happens depends entirely on the path.
./images/diagram.png almost never resolve, because the folder is not uploaded alongside the file.If a document depends on its diagrams, the pragmatic route is to swap relative paths for absolute URLs before converting — or convert the text and insert the images afterwards.
Markdown was written for a scrolling window. A PDF has pages, and that difference shows up most in code.
Long lines are the main problem. A browser lets a code block scroll sideways; paper cannot. A line longer than the page width is either wrapped at an arbitrary point or cut off at the margin. Neither is good in a document someone will read from, and cut-off code is genuinely misleading.
The fix is in your source: break long lines manually before converting, keeping them under roughly 80 characters. That is the traditional terminal width and it fits comfortably on A4 in a monospace font.
Blocks split across pages. A twenty-line function landing four lines from the bottom of a page continues overleaf, which is harder to follow than it sounds. Where a block matters, adding a little text before it to push it onto a fresh page is worth the effort.
Wide tables overflow. A pipe table with six columns of prose will not fit an A4 portrait page. Reduce the columns, shorten the cell contents, or accept that some tables belong on screen rather than on paper.
Markdown headings map directly to PDF document structure, and a well-organised source produces a genuinely better PDF.
Use one # for the document title and nest the rest properly — ## for sections, ### for subsections, without skipping levels. That hierarchy becomes the PDF's bookmark outline, giving readers a navigation panel, and it is the same structure screen readers use to move through a document.
Skipping from # straight to #### because it looked the right size is the common mistake. It reads fine and produces a broken outline.
One more habit: write real alt text in your image syntax rather than leaving  empty. It carries into the PDF and is the only thing a screen reader has to describe your diagrams.
Four situations where a PDF is the right answer.
Sending to someone who does not write Markdown. A client, a manager, a lawyer. Raw syntax reads as clutter to anyone outside the habit.
Printing. Documentation for a workshop, a spec to annotate by hand, notes for a meeting where laptops are closed.
Fixing a version. Markdown in a repository changes. A PDF is a snapshot of what the document said on a particular day, which matters for anything contractual or auditable.
Archiving. A PDF embeds its own fonts and layout, so it looks the same in a decade regardless of what renderers exist then.
TXT to Word handles plain text notes, Word to PDF gives you full control over styling first, and Compress PDF shrinks a documentation set for sharing. Browse all PDF tools.