Markdown to PDF
Paste Markdown or drop a .md file. GitHub-Flavored Markdown supported. 100% in your browser — nothing uploaded.
Drop a .md or .markdown file
or click to pick one — read into your browser only
Best for technical READMEs and notes. Tables are flattened, and external images are skipped for privacy.
Your file is ready
Processed entirely in your browser — the file never left your device.
How to convert Markdown to PDF
Three steps. Everything happens in your browser.
Paste or drop
Paste your markdown into the textarea or drop a .md file. The live preview shows what your output will look like.
Pick options
Page size, orientation, body font size, and code-block style. Defaults work for most README files.
Create & download
marked parses to HTML, the HTML tokenizes into blocks, and pdf-lib lays them out — all in your tab.
Why use Markdown to PDF on imisspdf?
Source stays on your machine
Markdown often contains internal notes, draft posts, or API keys in code blocks. Nothing is uploaded — every byte of the pipeline runs locally.
Fast for technical docs
Headings, lists, and fenced code render cleanly at a glance. No print dialog, no Chrome screenshot — paste, click, download.
GFM supported
Strikethrough, task lists, fenced code blocks, autolinks — the parser is marked in GFM mode. Tables are flattened (we say so up-front).
What "Markdown to PDF" means here
Markdown is the format most developers and technical writers actually compose in — README files, blog drafts, runbooks, API docs, internal wikis. It is light, version-controllable, and renders cleanly on GitHub. But when it is time to share that document with someone who does not work in your repo, a PDF is usually the right delivery format: it prints predictably, opens on any device, and does not depend on the recipient having a markdown viewer installed.
imisspdf's Markdown to PDF tool takes the markdown source you paste (or drop as a .md file) and produces a single PDF in your browser. Headings keep their hierarchy, lists stay indented, fenced code blocks render in a monospace font, and quotes / horizontal rules look like quotes and rules. The result is a clean, no-frills PDF that is appropriate for a README, a technical brief, or a change-log handed to a non-technical reader.
How the conversion works
Three stages run end-to-end in your tab:
- The marked parser turns your markdown into HTML with GFM rules enabled (fenced code, strikethrough, task lists, autolinks).
- A small regex-based tokenizer walks the HTML into a flat sequence of block tokens — headings, paragraphs, lists, code blocks, quotes — and their inline runs (bold, italic, inline code, links).
- pdf-lib lays the blocks onto pages using the PDF Standard 14 fonts (Helvetica for body, Courier for code). New pages are added as content overflows.
Nothing in this pipeline talks to a server. There is no markdown rendered remotely, no headless Chromium spinning up in a cloud function, and no temp file held for "an hour to comply with retention". The PDF is built in JavaScript bytes you can see being written in your DevTools.
When this is the right tool — and when it is not
This tool is right when you need a clean, archival PDF of technical content: a README, a runbook, a markdown-authored brief, meeting notes, a tutorial. It handles inline formatting, lists, code, and quotes the way you would expect for that kind of document.
It is the wrong tool when you need pixel-fidelity with a rendered site (use your browser's Save as PDF on the rendered page), when you need typeset tables (use Pandoc + LaTeX locally), or when you need syntax-highlighted code (export from your editor as HTML and run HTML to PDF). We name the limits up-front so you can pick the right workflow.
Privacy & security
Markdown is one of the formats most likely to contain things you would not want on a server: API keys in code blocks, internal URLs in links, draft posts you have not published yet, customer names in meeting notes. Server-based markdown-to-PDF tools have to ingest all of that. The architecture of this tool means you do not have to take a privacy policy on trust — there is simply no upload step in the pipeline. Block your network and the conversion still works after the page has loaded.
Frequently asked questions
Yes — the parser runs in GFM mode, so fenced code blocks (with ``` backticks), strikethrough (~~text~~), task lists, autolinks, and the GFM relaxed paragraph rules all work. What does not survive the conversion is tables: marked produces an HTML <table>, but the PDF renderer in this tool does not draw table cells, so a table will come out as flattened text lines. If your README leans heavily on tables, render the page in GitHub first and then use HTML to PDF or screenshot it for a true grid output.
No. Code blocks are rendered in a fixed-width Courier font on a single color so the indentation and structure of the code stay legible, but tokens are not coloured by language. We deliberately skip syntax highlighting because it would force loading a 200 KB+ highlight library on a page whose primary job is converting to PDF, and PDFs are usually printed or archived — not read like an IDE. If colored code matters, paste the highlighted HTML from your editor through our HTML to PDF tool instead.
External image tags () are dropped — the tool will not fetch remote images. This is deliberate for two reasons: privacy (a fetch would leak your IP and referer to the image host) and reliability (network-dependent rendering means inconsistent output). If you need images embedded in the PDF, use the JPG to PDF or PNG to PDF tools to add them as separate pages, or merge them with the markdown-rendered PDF using Merge PDF.
No. Both the markdown source and the rendered PDF stay entirely inside your browser tab. The marked parser, the HTML-to-block tokenizer, and pdf-lib are all client-side JavaScript loaded once on this page and then run locally. You can confirm in your browser DevTools Network tab — after the page loads, generating a PDF makes zero outbound network requests. Close the tab and every trace is gone; there is no server-side temp file because there is no server step.
All six markdown heading levels (# through ######) render as PDF headings with decreasing sizes (h1 is largest, h6 is barely larger than body text). The hierarchy is preserved so screen readers and PDF readers will pick up the outline. Inside headings, inline formatting (bold, italic, inline code) is honoured. We do not auto-generate a table of contents — if your document needs one, add a "## Table of contents" section yourself with a simple markdown list.
Not in their grid form. marked parses the table correctly into HTML, but our PDF renderer is a deliberately simple one and does not draw cell borders or distribute columns. The table will come out as a sequence of text lines, row by row, which is usually unreadable for anything more than a 2x2 example. If tables are essential to your document, the honest workflow is: render to HTML in your favourite previewer, take a screenshot, and use JPG to PDF — or use Pandoc locally for a full LaTeX-grade output. We are upfront about the limitation rather than pretending to render tables badly.
Tips for good output
- Use real headings. A
#at the start of a line becomes h1; lower levels nest cleanly. PDF readers and screen readers pick up the outline. - Keep code blocks fenced. Triple-backtick blocks render in Courier so indentation reads correctly even when wrapped.
- Skip image-heavy markdown. External images are not fetched. Convert images to PDF separately and merge them.
- For tables, render the markdown in your tool first, then screenshot. Or use Pandoc locally for typeset tables.
Related PDF tools
- HTML to PDF — same renderer, HTML input instead of markdown.
- TXT to PDF — plain text without any formatting.
- Merge PDF — combine the markdown PDF with images or other files.
- Compress PDF — shrink the output for sharing.