How to Convert a Markdown File to PDF or HTML

Markdown is great for writing — fast, distraction-free, plain text you can edit in any tool. Markdown is bad for sharing — most people you’d send it to have no idea what those asterisks and pound signs mean, and even readers who know Markdown won’t see the document rendered the way you intended unless they paste it into a renderer.

To send something readable, you convert. PDF for a polished, printable document. HTML for the web (a blog, a wiki, a static site). Here’s how, without installing anything.

The fastest way: convert in your browser

Two tools depending on output:

Markdown to PDF — renders your .md to PDF
Markdown to HTML — renders your .md to HTML

Drop in the .md file, get back a rendered version. Conversion is instant.

The flow:

Open the Markdown to PDF tool (or Markdown to HTML)
Drag in your .md file (or paste markdown text directly)
The tool parses the markdown using the standard CommonMark spec + GitHub Flavored Markdown extensions
For PDF: it renders to HTML internally, then prints that HTML to PDF
Click save
The result downloads

Runs entirely in your browser. Your markdown content never gets uploaded.

What’s supported

Both tools handle the full CommonMark spec plus the common GitHub Flavored Markdown (GFM) extensions:

Core CommonMark:

Headings (# through ######)
Bold (**bold**), italic (*italic*), strikethrough (~~strike~~)
Lists (ordered and unordered, nested)
Code blocks (fenced with triple backticks) and inline code
Block quotes (> like this)
Links and images
Horizontal rules
Paragraphs and line breaks

GFM extensions:

Tables (with | separators)
Task lists (- [x] done, - [ ] not done)
Strikethrough text
Auto-detected URLs as links
Fenced code with language hints for syntax highlighting (when output is HTML)

Not supported (these are extensions beyond core/GFM):

Math equations (LaTeX-style $x = y$ ) — need a math-aware tool
Mermaid diagrams (```mermaid blocks) — need a diagram-aware tool
Footnotes (some renderers support them; ours doesn’t currently)
Custom directives / front matter
HTML embedded inside markdown (partially works for simple tags like <br> and <sub>; complex HTML may break the output)

For the common writing use case — articles, documentation, READMEs, notes — everything just works.

Markdown to PDF: layout and styling

The PDF output uses a clean, readable default style: serif body font, sans-serif headings, sensible margins, automatic page breaks at headings. The result looks like something you’d be comfortable handing to a coworker.

What gets preserved in the PDF:

All text and formatting (bold, italic, strikethrough)
Heading hierarchy with proper sizing
Lists with bullets and numbering
Tables, properly aligned
Code blocks in monospace with a subtle background
Images embedded inline (referenced by URL in the markdown)
Hyperlinks as clickable links in the PDF

What you can’t easily customize without a more advanced tool:

Font choice (limited to a sensible default)
Page margins
Custom CSS styling
Headers and footers
Watermarks or page numbers

For a fully styled PDF (specific brand fonts, custom layouts, headers/footers with page numbers), the workflow is usually:

Convert markdown to HTML with our Markdown to HTML tool
Open the HTML in a browser, apply custom CSS
Use browser “Print to PDF” with the CSS-styled view

That’s more steps but gives full control. For most “I just want a readable PDF version of this markdown” cases, the direct converter is enough.

Markdown to HTML: what comes out

The HTML output is clean, semantic, self-contained:

Standard semantic tags (<h1>, <p>, <ul>, <code>, etc.)
A simple CSS stylesheet embedded in the head (so the file is self-contained and looks decent when opened in a browser)
All content escaped properly (no XSS risk from markdown that contains HTML-looking strings)
UTF-8 encoded
Valid HTML5

Common uses:

Publishing to a static site — paste the HTML into your CMS, blog editor, or static site generator
Sharing a doc that needs to display in a browser — emails, wiki entries, intranet pages
Email newsletters — most email clients render basic HTML; markdown-converted HTML is exactly the kind they handle well
Web-based slideshows — converted HTML can be styled with reveal.js or similar slide frameworks

If you want just the content HTML (no <html><head><body> wrapper, for pasting into a CMS that wraps content automatically), most CMSes strip the wrapper anyway. If your destination is picky, manually trim the wrapper to leave just the rendered body content.

Common gotchas

Image URLs. Markdown like ![alt text](image.png) references images by URL or relative path. When you convert to PDF or HTML, those references stay as references — the actual image needs to be accessible at that URL (or sit alongside the HTML file at the relative path). For self-contained output, host images on a public URL or embed them as base64 data URIs (a more advanced workflow).

Relative links between markdown files. A markdown doc with [next chapter](chapter-2.md) keeps the .md reference in the output. After converting to HTML, those links go to non-existent files. Fix: search-replace .md → .html after conversion, or use a static site generator that handles cross-references properly.

Tables that look fine in your editor but break in conversion. Markdown tables require:

A header row (always)
A separator row immediately below (with dashes)
Properly aligned | characters across all rows

If your editor “helpfully” reformats your markdown, it can break the table. Stick to a strict format.

Empty lines inside lists. A common gotcha: an empty line inside a markdown list interrupts the list, so the second half renders as a new list. Either remove empty lines within lists, or use <br> for an explicit line break within a list item.

Code fences without closing. A code block opened with but missing its closing will swallow the rest of the document into the code block. Easy to do, hard to spot. If the converter shows weird output toward the end of your file, check for an unclosed code fence earlier.

Going the other direction (HTML or PDF → Markdown)

Markdown is a write-side format. Converting back from HTML or PDF to markdown is harder — both formats have richer styling capabilities than markdown can express, so the conversion involves dropping information.

For occasional needs:

HTML → Markdown: tools like Pandoc (free, command-line) and online converters do a decent job for clean HTML. Output usually needs manual cleanup for anything beyond simple articles.
PDF → Markdown: doable for well-structured PDFs (academic papers, books) but unreliable for complex layouts. PDF → text → manual markdown is often cleaner than automated PDF → markdown.

We don’t have these tools (yet) because the quality of the output is too unpredictable to recommend. Pandoc remains the best option for these reverse conversions if you’re comfortable with command-line tools.

A typical workflow

For someone writing technical documentation in markdown:

Draft in your favorite markdown editor (Obsidian, VS Code, iA Writer, plain text editor)
Preview frequently in the editor’s preview pane
When ready to share:
- For a PDF copy → Markdown to PDF
- For a web page → Markdown to HTML
- For a Word doc → first convert to HTML, then open the HTML in Word and save as DOCX. (No direct .md → .docx tool because the use case is rare; Word can import HTML cleanly.)
Share the final artifact, keep the .md as the editable source of truth

This way the markdown source is your “master copy” — easy to version-control, edit anywhere, future-proof — and the rendered outputs are throwaway artifacts you regenerate when content changes.

Privacy

Both tools run in your browser:

Markdown is parsed by marked (an open-source JavaScript markdown parser)
HTML rendering happens with browser-native DOM construction
PDF rendering uses the browser’s built-in print-to-PDF (no upload)
Nothing about your document ever touches a server

For documentation that’s sensitive (internal company docs, draft blog posts, personal notes), browser-based conversion means no leak risk.

TL;DR

Markdown → PDF for sharing → Markdown to PDF
Markdown → HTML for web/email → Markdown to HTML
Both handle CommonMark + GFM (tables, task lists, strikethrough)
Images stay as references — host them somewhere accessible, or paste in inline
Markdown is the editable source; PDF/HTML are throwaway outputs
Runs in your browser, no upload, no signup