Convert Markdown to PDF in five steps
- 1Open the tool. Go to pdfgami.com/markdown-to-pdf in any current browser. There is nothing to install and no account to make.
- 2Get the Markdown in. Paste it into the left pane, or drop a file —
.md,.markdown,.mdown,.mkdand.txtare accepted, one at a time, up to 300,000 characters. If you just want to see what the renderer does, there is a sample document one click away. - 3Read the preview.The right pane is labelled “this is what prints” and it means it literally: printing hides the rest of the page rather than re-rendering the document, so the preview and the PDF cannot drift apart. A word count sits above the editor and a heading count above the preview.
- 4Set the title and page breaks. Type a Title — it becomes the suggested filename in the print dialog — and decide whether every second-level heading should start a fresh page.
- 5Save as PDF.The button opens your browser's print dialog. Choose Save as PDF as the destination rather than a printer, and the document lands in your downloads folder with its text intact.
What “without losing the formatting” really means
That phrase gets typed into search boxes by people who have already been burned once, usually by a converter that supported original 2004 Markdown and nothing since. The features that break are almost always the GitHub Flavoured ones — tables and task lists above all — because they were never part of the original spec and a parser has to opt into them. PDFGami turns GFM on, so the document you wrote for a repository renders the way it does in the repository.
Concretely, all of the following make it into the PDF: headings at every level, each with an anchor id so internal #section links still work; bold and italic; links, which stay clickable; images; ordered, unordered and nested lists; task lists with real checkboxes rather than bracket characters; tables; blockquotes; horizontal rules; inline code; and fenced code blocks. Headings also feed an outline panel underneath the editor, which is a fast way to check the structure of a long document before you commit it to paper.
Hard line breaks are off. A single newline in the middle of a paragraph is a wrap in Markdown, not a line break, and the renderer treats it that way. If you hard-wrap your source at 80 columns — plenty of people do — your paragraphs come out as paragraphs instead of as a ragged column of short lines. To force a break, use the Markdown that means it: two trailing spaces, or a blank line for a new paragraph.
Why the export goes through the print dialog
This is the question the tool gets asked most, so here is the straight answer: a web page cannot write a PDF to your disk on its own. Something has to generate the file, and in a browser-only tool there are exactly two ways to do it.
The first is to draw the rendered document onto a canvas and wrap the resulting bitmap in a PDF. That route was available here — html2canvas is already a dependency of this project, so it would have been the smaller piece of work — and it was turned down deliberately. What it produces is a picture of your text. You cannot select a sentence, a find-in-page search returns nothing, a screen reader sees an empty page, pasting a paragraph into an email is impossible, and the whole thing goes soft the moment anyone zooms in. It looks like a PDF in a thumbnail and behaves like a screenshot everywhere else.
The second is to hand the page to the browser's own print pipeline, which is a real PDF writer with real font embedding. Text stays text, headings stay headings, links stay links, and for a text-heavy document the file lands far smaller than the rasterised version. The cost is one extra click: you pick Save as PDF as the destination instead of a printer. The tool says so on the page rather than hiding it, because the alternative is a download button that silently hands you a worse document.
If you have ever wondered why a PDF you received cannot be searched, this is usually why: someone exported it as an image. You can test any PDF in a few seconds by dropping it into the PDF to text extractor. If text comes out, it is a text PDF. If nothing does, it is a picture, and you will need OCR to get anything back out of it. Documents printed from the Markdown tool pass that test.
Two things the renderer will not do
Both of these are worth knowing before you convert rather than after, and neither is a bug.
No syntax highlighting inside code blocks
Fenced code blocks are rendered in plain monospace. Indentation, line breaks and every character are preserved exactly, and the block is kept whole across page boundaries, but keywords and strings are not coloured. For a changelog or an API snippet that is fine and arguably better in print. For a teaching document where the colouring carries meaning, render it somewhere that ships a highlighter.
No Mermaid diagrams
A ```mermaid block is an ordinary fenced code block here, so the diagram source prints as text. If your architecture document leans on Mermaid, export each diagram as a PNG or SVG from whatever renders it, reference it with normal Markdown image syntax, and it prints as a picture.
There is no theme picker, no PDF metadata editor, and no batch mode that converts a folder of files in one pass. One document at a time, rendered one way. If you need several finished PDFs bound into a single deliverable, print them separately and combine them with the PDF merger, which also runs entirely in the browser.
Page breaks, margins and paper size
A long Markdown document printed with no thought about pagination is where formatting complaints actually come from. A table splitting across two sheets, a heading alone at the bottom of a page with its section starting overleaf, a code block cut in half — all of that reads as a broken conversion even though every character made it through.
The print rules handle the common cases without you doing anything. Code blocks, tables and blockquotes are told not to break internally. Headings are told not to be the last thing on a page, so a heading moves forward to sit with the text it introduces. The page itself is given an 18mm margin at the top and bottom and 16mm at the sides, which is a comfortable measure for a printed report and stops long table rows running to the paper edge.
One control is yours: the Start each section on a new page checkbox inserts a page break before every second-level heading. For a document structured with ## per chapter or per client, that turns one continuous scroll into a set of clean sections. The first heading is left where it is, so you do not get a blank opening page.
Everything beyond that belongs to the print dialog, which is the right place for it: paper size, portrait or landscape, scale, and whether headers and footers are printed. Those are browser settings that already exist and work well, and duplicating them in the page would only give you two places to be confused by.
Why a Markdown renderer has to sanitise
Markdown is a superset of HTML by design. Raw tags are allowed to pass through, which is convenient when you want a bit of markup the syntax does not cover and dangerous the moment the document came from somewhere else — a README off a repository you are reviewing, a spec a vendor sent, anything generated by a tool you did not write. A converter that injects the parser's output straight into the page is running whatever that document contains.
So there are two libraries here, both load-bearing: marked parses the Markdown, and DOMPurify sanitises the HTML it produces before anything reaches the preview. That order matters, and so does the fact that the anchor ids on headings are added after sanitising rather than before — ids cannot be used to smuggle anything past the filter if the filter has already run.
A document containing a <script> tag, an onerror attribute, an <iframe>, an inline style attribute and a stray <input type=text> was pasted into the tool. All five were removed from the rendered output and none of the payloads executed. The one exception is deliberate: GFM task-list checkboxes survive, because forbidding the input tag outright turned every checklist into plain bullets. Any input that is not a checkbox is dropped, and the checkboxes that remain are rendered disabled — a printed checklist should not look clickable.
The other half of the safety story is that nothing is uploaded. Parsing, sanitising, rendering and printing all happen in the tab; there is no server step, so there is no copy of your document on anyone's disk and no retention policy to read. You do not have to take that on trust, either. Open your developer tools, switch to the Network tab, and convert a document: a browser-only tool stays quiet while a server-backed one shows a request the size of your file. Are online PDF tools safe? walks through that check in more detail, and it is worth running on any converter before you feed it something confidential.
Titles, filenames and the Copy HTML button
The Title field does one specific job: it sets the document title, and the document title is what browsers offer as the suggested filename in the print dialog. Leave it empty and you get whatever the page happens to be called, which is rarely what you want to send someone. Drop a file in and the field is filled from the filename with its extension stripped, so release-notes.md becomes release-notes. It is not PDF metadata editing — the tool does not claim to write author or keyword fields — just a sensible name on the file you are about to save.
Next to the save button there is a Copy HTML button, which puts the sanitised markup of the rendered document on your clipboard. That is the useful escape hatch when the destination is not a PDF at all: an email client, a CMS field, a wiki page, a Word document that someone else insists on. Because the HTML has already been through the sanitiser, it is the clean version rather than the raw parser output.
A Clear button empties both panes when you want to start again, and a warning strip appears rather than a silent failure whenever something needs saying — a file with an extension the tool does not accept, a document over the 300,000-character limit, or a browser that blocked clipboard access.
Frequently asked questions
How do I convert a Markdown file to PDF without installing anything?
Open the Markdown to PDF tool, drop the .md file onto the page or paste the text into the left pane, then click Save as PDF and choose "Save as PDF" as the destination in your browser's print dialog. There is no install, no account and no upload: marked parses the Markdown and DOMPurify sanitises it, both in JavaScript inside the tab you already have open.
Why is there no direct download button?
Because a web page cannot write a file to your disk by itself. The two honest routes are the print dialog, which hands the rendered page to the browser's own PDF writer, or drawing the page onto a canvas and wrapping that image in a PDF. The canvas route is genuinely available — html2canvas is already installed in this project — and it was rejected on purpose, because it produces a picture of your text: nothing selectable, nothing searchable, and soft at any zoom. Printing keeps the text as text.
Which Markdown features survive the conversion?
GitHub Flavoured Markdown, which is what people actually write: headings, bold and italic, links, images, ordered, unordered and nested lists, task lists with real checkboxes, tables, blockquotes, horizontal rules, inline code and fenced code blocks. Headings also get anchor ids, so internal #links inside the document keep working, and they populate an outline panel below the editor.
Does the code in my fenced code blocks get syntax highlighting?
No. Fenced code blocks are rendered in plain monospace, with the block kept intact across page breaks but with no colouring of keywords or strings. If highlighted code is the point of the document — a tutorial, say — render it somewhere that ships a highlighter and print that instead. Everything else about the block, including indentation and line breaks, is preserved exactly.
Will Mermaid diagrams in my Markdown be drawn?
No. A ```mermaid block is treated as an ordinary fenced code block, so the diagram source prints as text rather than as a picture. That is worth knowing before you convert an architecture document. Export the diagram as an image from whatever draws your Mermaid, reference it with normal Markdown image syntax, and it will print as an image.
Is it safe to convert a Markdown file I did not write?
That is the case the sanitiser exists for. Markdown is a superset of HTML, so any document can contain a raw script tag, an onerror attribute, an iframe or an inline style. The renderer runs everything through DOMPurify before it touches the page: a test document carrying a script tag, an onerror attribute, an iframe, an inline style and a stray text input had all five stripped and none of the payloads ran. Task-list checkboxes are the one input that survives, and they are rendered disabled.
How large a document can it handle?
Up to 300,000 characters, which is a few hundred pages of prose. Drop something longer and the tool loads the first 300,000 characters and tells you it did, rather than failing silently. Accepted file extensions are .md, .markdown, .mdown, .mkd and .txt — anything else is refused with a message naming the file.
Can I control where the page breaks fall?
Partly, and the useful part is one checkbox: "Start each section on a new page" puts a page break before every second-level heading, so a report with ## per chapter comes out one chapter per page. Beyond that the print rules avoid splitting code blocks, tables and blockquotes across pages and avoid stranding a heading at the foot of one. Paper size and any margin other than the built-in 18mm top and bottom, 16mm left and right belong to the print dialog itself.
Convert your Markdown now
Paste the document or drop the .md file, check the preview, print it to PDF. Free, no account, and the file never leaves your browser.