How to Convert Markdown to PDF on Windows, Mac, Linux and iPad

The methods available to you depend less on your operating system than most guides suggest — a browser works everywhere, and Pandoc runs on all three desktop platforms. What genuinely differs is what is already installed, how you install what is missing, and what fonts you can count on.

This guide covers each platform concretely, then the offline question, which is the one people usually actually mean when they ask about platform support.

Choosing an approach

Four broad approaches, on any platform:

Approach	Setup	Best for	Trade-off
Browser-based tool	None	One-off conversions, visual iteration	No batch processing or citations
Editor with export	Minutes	Regular work in one app	Styling limited to what the app allows
Pandoc	10–30 min	Citations, cross-references, batch, multi-format	Toolchain to install and learn
Headless browser script	30+ min	Automated pipelines, CI	Code to maintain

Most people want the first or second. Reach for Pandoc when you need citation processing or DOCX output alongside PDF — see the Pandoc comparison for where that line falls.

Windows

Browser (no installation)

Windows ships with Edge, which is Chromium — its print engine handles print CSS well. Open any browser-based Markdown converter, paste, export. This is the fastest path and needs nothing installed.

Edge’s own Print to PDF works on any rendered HTML: Ctrl+P, choose Microsoft Print to PDF or Save as PDF. Note that Edge’s print dialog has a Background graphics toggle that is off by default — with it off, code block backgrounds and table shading disappear. Turn it on under More settings.

VS Code

If you already write in VS Code, its Markdown preview plus a print step covers most needs. See the dedicated VS Code guide for extension options and settings.

Pandoc

The most convenient install is via winget, which is built into Windows 11:

winget install --id JohnMacFarlane.Pandoc

Or Chocolatey:

choco install pandoc

Pandoc alone cannot produce PDF — it needs a PDF engine. Two choices:

MiKTeX (LaTeX, best typography, large):

winget install --id MiKTeX.MiKTeX

MiKTeX installs packages on demand the first time a document needs them, so your first conversion is slow and subsequent ones are fast. It will prompt for permission to install; if you are scripting, set it to install automatically in the MiKTeX Console.

wkhtmltopdf (HTML-based, much smaller, weaker typography):

winget install --id wkhtmltopdf.wkhtmltopdf

Then:

# Via LaTeX
pandoc document.md -o document.pdf --pdf-engine=xelatex

# Via HTML with your own stylesheet
pandoc document.md -o document.pdf --pdf-engine=wkhtmltopdf --css=print.css

A caveat about wkhtmltopdf: it is built on a very old Qt WebKit and is effectively unmaintained. It does not support modern CSS — no Grid, patchy Flexbox, no @page margin boxes. It works for simple documents and will frustrate you on anything styled. Prefer LaTeX for quality or a headless Chrome script for CSS fidelity.

PowerShell batch conversion

Get-ChildItem -Filter *.md | ForEach-Object {
  $out = [IO.Path]::ChangeExtension($_.Name, "pdf")
  pandoc $_.FullName -o $out --pdf-engine=xelatex
  Write-Host "Converted $($_.Name)"
}

Fonts on Windows

Windows ships Calibri, Cambria, Consolas, Georgia, Segoe UI and Times New Roman. Segoe UI Emoji covers emoji. Consolas is a genuinely good monospace for code — better than Courier New, which you should avoid.

Font files live in C:\Windows\Fonts (system-wide) or %LOCALAPPDATA%\Microsoft\Windows\Fonts (per-user). Per-user installs do not require admin rights, which is useful on a locked-down work machine.

WSL

If you use WSL, follow the Linux instructions inside it. Two things to know: WSL cannot see Windows fonts by default, so install fonts in the Linux filesystem, and paths differ — /mnt/c/Users/you/Documents is your Windows Documents folder. Converting a file on the Windows filesystem from WSL works but is noticeably slower than working within the Linux filesystem.

macOS

Browser and Quick Look

Safari and Chrome both print to PDF via Cmd+P → Save as PDF. Safari’s print engine is WebKit and slightly less capable than Chromium for print CSS; if a document renders oddly in Safari, try Chrome before debugging your CSS.

macOS’s Quick Look previews Markdown files with Space in Finder, but the preview is plain text unless you install a Quick Look plugin. It is not a conversion path.

Homebrew

brew install pandoc

# A LaTeX engine — basictex is ~100MB vs mactex's ~4GB
brew install --cask basictex

# Or the full distribution
brew install --cask mactex

basictex is the right default. It omits packages most documents never use, and you add what you need:

sudo tlmgr update --self
sudo tlmgr install collection-fontsrecommended

If a conversion fails with a missing .sty file, tlmgr install <package> fixes it. The error message names the file; the package usually shares the name.

TextEdit and Preview

Not a real path, but worth knowing: TextEdit can open a Markdown file as plain text and print to PDF, giving you an unstyled monospace dump. Occasionally useful for archiving raw source; useless for a document anyone reads.

Automator and Shortcuts

macOS lets you wrap conversion in a right-click action. In Automator, create a Quick Action taking files as input, add Run Shell Script with Pass input: as arguments:

for f in "$@"; do
  /opt/homebrew/bin/pandoc "$f" -o "${f%.md}.pdf" --pdf-engine=xelatex
done

Use the absolute path to pandoc — Automator does not inherit your shell’s PATH, which is the single commonest reason these scripts fail silently. /opt/homebrew/bin on Apple Silicon, /usr/local/bin on Intel.

Save it and Markdown files gain a Convert to PDF entry in the Finder right-click menu.

Fonts on macOS

macOS ships an unusually good font library: Helvetica Neue, Avenir Next, Georgia, Palatino, Optima, plus SF Pro and SF Mono. Apple Color Emoji covers emoji properly.

Note that SF Pro and SF Mono are licensed for use on Apple platforms and are not freely redistributable. Embedding them in a PDF is a grey area; if the document is going to be widely distributed, use an open font instead. Menlo (also preinstalled) has a more permissive history and is a reasonable monospace fallback.

Fonts install to ~/Library/Fonts (per-user) or /Library/Fonts (all users) — just drag the file, or double-click and use Font Book.

Linux

Package managers

# Debian / Ubuntu
sudo apt install pandoc texlive-xetex texlive-fonts-recommended

# Fedora
sudo dnf install pandoc texlive-xetex

# Arch
sudo pacman -S pandoc texlive-bin texlive-fontsextra

# openSUSE
sudo zypper install pandoc texlive-xetex

Distribution Pandoc packages often lag several versions behind. If you need recent features — particularly anything citation-related — install from the release binary instead:

VERSION=3.6.2
curl -LO "https://github.com/jgm/pandoc/releases/download/${VERSION}/pandoc-${VERSION}-1-amd64.deb"
sudo dpkg -i "pandoc-${VERSION}-1-amd64.deb"

WeasyPrint

Worth knowing about on Linux specifically, because it is the best CSS-based option and installs cleanly:

pip install weasyprint

# System dependencies on Debian/Ubuntu
sudo apt install libpango-1.0-0 libpangoft2-1.0-0 libharfbuzz0b

WeasyPrint implements CSS Paged Media properly — @page margin boxes, string-set, target-counter(), footnotes — which puts it ahead of headless Chrome for document work. Pipe Markdown through it:

pandoc document.md -t html5 --standalone --css=print.css \
  | weasyprint - document.pdf

Its one significant limitation is no JavaScript execution, so Mermaid diagrams and MathJax will not render. KaTeX pre-rendered to HTML works fine.

Headless Chrome

google-chrome --headless --disable-gpu --no-sandbox \
  --print-to-pdf=output.pdf \
  --no-pdf-header-footer \
  document.html

--no-pdf-header-footer suppresses Chrome’s default date-and-URL furniture, which otherwise appears on every page. Note that this route gives you no @page margin box support — see the headers and footers guide.

Fonts on Linux

The one platform where you cannot assume anything is installed. A minimal container has no fonts at all, which produces documents in whatever fallback fontconfig finds — or blank boxes.

sudo apt install fonts-liberation fonts-dejavu fonts-noto-color-emoji
fc-cache -fv

Liberation fonts are metric-compatible substitutes for Arial, Times New Roman and Courier New, which means a document specifying Arial lays out identically. That property makes them the right choice for reproducing documents authored on Windows.

fonts-noto-color-emoji is the fix for emoji rendering as boxes — the most common Linux-specific conversion complaint, and the reason “it works locally but not in CI” happens. See the typography guide for the Docker line.

Check what a font name resolves to:

fc-match "Helvetica"
# → LiberationSans-Regular.ttf if Helvetica is absent

If fc-match returns something unexpected, your document is not rendering in the font you think it is.

iPad and iOS

The most constrained platform, and the one where a browser-based tool has the clearest advantage — there is no Pandoc for iPadOS, and no way to install one.

Browser

Safari on iPadOS is a full browser. A browser-based Markdown converter works normally, including file download to the Files app. This is the realistic path on iPad and it works well.

One iPadOS-specific note: Safari can request the desktop version of a site via the aA menu, which occasionally matters for tools with a mobile layout that hides advanced controls.

Editor apps with PDF export

Several Markdown editors on iPad export PDF directly:

App	Notes
iA Writer	Clean export, limited template control, has a distinctive default style
Ulysses	Good export with customisable styles; subscription
Obsidian	Full vault sync, export via the core PDF function
Taio	Strong automation support, actions system
Textastic	Code-focused, basic preview and print

These are convenient and constrained: you get the styling the app provides, with limited or no custom CSS. For a resume or a report where layout matters, the browser route with your own CSS gives more control.

Print to PDF via the share sheet

iOS has a hidden universal PDF export: bring up the print dialog from any app’s share sheet, then pinch outwards on the print preview thumbnail. The preview expands into a PDF you can share or save. It is genuinely obscure and works from Safari, Files, and most apps that support printing.

Shortcuts

The Shortcuts app can build a small conversion pipeline without any code:

1. Get File — pick the Markdown file
2. Get Text from Input
3. Make HTML from Markdown — a built-in action
4. Make PDF from Input
5. Save File

That is a complete offline Markdown-to-PDF converter using only Apple’s built-in actions. The styling is minimal and not configurable, but for quick conversions it is fast and requires nothing installed. Add it to the share sheet and it becomes a one-tap action on any .md file.

What you cannot do on iPad

No Pandoc, so no citation processing, no cross-references, no DOCX output. No headless browser scripting. No custom font installation for use in a browser context (iOS font profiles apply to apps that opt in, not to Safari’s rendering of your CSS). For citation-heavy academic work, the iPad is a drafting device; final production happens elsewhere.

Working offline

This is usually the real question behind “does it work on my platform” — people want to know whether their document leaves their machine.

Two distinct concerns worth separating:

Does it work without a network connection? A practical concern on a plane or in a facility without internet.

Does my content get uploaded? A privacy concern about where the document goes.

They are not the same. A tool can require a network connection to load and still process everything locally.

Genuinely offline options

Method	Offline after setup	Content stays local
Pandoc	Yes	Yes
WeasyPrint	Yes	Yes
Headless Chrome script	Yes	Yes
Desktop editor export	Yes	Yes
iOS Shortcuts	Yes	Yes
Browser tool, client-side	Only if cached	Yes
Browser tool, server-side	No	No — uploaded

The last two rows are the distinction that matters. A client-side browser tool downloads its code once and then does all parsing and PDF generation in your browser’s JavaScript engine — your content never goes to a server. A server-side tool uploads your text, converts it remotely, and sends back a file.

You cannot tell which is which from the interface. Two ways to check:

Open developer tools, Network tab, then convert. A client-side tool makes no request carrying your content. A server-side tool makes an obvious POST with your document in the body.

Load the page, disconnect from the network, then convert. If it still works, everything is happening locally. This is the more convincing test and takes ten seconds.

For a document containing anything you would not paste into a public forum — a resume with your address, a contract, an internal runbook — that ten-second test is worth doing once on whatever tool you use.

Making a browser tool work offline

A client-side converter with a service worker can be installed as a PWA and work with no connection at all. On desktop Chrome or Edge, look for an install icon in the address bar; on iPad, Share → Add to Home Screen. After the first load, the application code is cached and conversions run with the network off entirely.

Try it yourself

The editor here runs entirely in your browser on every platform above, including iPad — Markdown parsing, pagination and PDF generation all happen client-side, so nothing is uploaded. You can verify that with either test described above: check the Network tab, or disconnect and convert anyway.

For citation processing, batch conversion or DOCX output, Pandoc is the better tool — the comparison guide covers where each fits.