You write in Markdown—plain text, version control, focus on content—but downstream wants Word or PDF. The issue is not Markdown itself; it is how to turn structured plain text into a typeset deliverable without loss. Three main approaches exist; each has different pitfalls.
Why Can't You Just Send Markdown as Word?
A .md file is source; .docx / .pdf are finished layout—they live at different layers. ## Heading in .md is only a marker; without a renderer, recipients see plain text with #, no font sizes, no table of contents, no page numbers. Clients, advisors, and admin staff work in Office and PDF; sending .md is sending a work-in-progress.
Delivery is therefore a format conversion: map Markdown structure (headings, lists, code, tables, images) to the target format's layout elements. Quality depends entirely on choosing the right conversion path.
What Are the Main Ways to Convert Markdown to Word / PDF?
Three mainstream paths, ordered by convenience vs. control:
| Method | Best for | Cost |
|---|---|---|
| Copy rendered HTML into Word | Short snippets | Web styles; font/line spacing often wrong |
| pandoc / wkhtmltopdf CLI | Batch, automation, custom templates | Install, flags, font setup |
| Browser online conversion | Occasional single file, need result now | Very long docs hit browser memory |
None is universally best: CI pipelines batching PDFs → pandoc; occasional handoff of one .md → installing pandoc and tuning templates often costs more than a browser conversion.
How Do You Convert .md to Word/PDF in the Browser?
For occasional delivery, browser conversion is simplest: no install, no flags, no cross-platform font wrestling. Drop .md into the Markdown convert tool, pick the target format on the right, start conversion, download. Key points:
- PDF uses professional typesetting fonts (e.g. Source Han Serif class), syntax-highlighted code blocks, clear table borders—"email to client" quality;
- Word outputs real
.docxstructure, not "HTML renamed," so styles remain editable in Word; - Light/dark themes: same
.mdcan export light (print/client) or dark (screenshots/sharing); - Local processing: conversion runs in the browser; source and export never leave your device.
Fix Format Before Converting—Fewer Surprises
Bad conversion often traces to messy source Markdown: missing space after #, inconsistent list indent, ordered lists all written as 1.. Previewers may "accidentally" look fine; another engine may parse differently.
Before formal delivery, run .md through the Markdown lint tool—one click fixes heading spaces, list indent, trailing spaces, and more—then convert. Results stabilize. Especially useful for .md files from others with sloppy formatting.
Images, Long Documents, and Fonts—Where Conversions Fail
Three common failure points:
- Local images: use the converter's "insert image" control; images embed in the export. Remote image URLs load at conversion time; if the server blocks CORS, a placeholder appears instead of failing the whole job.
- Long documents: 80–150 page theses usually stable; 200+ pages—split by level-2 headings, export separately, merge—avoids single-shot browser memory pressure.
- Fonts: for Chinese delivery, prefer built-in professional serif/sans fonts; avoid fonts only on your machine—PDF embeds fonts fine, but editable Word for others should use common faces.
Boundaries: When pandoc Beats the Browser
Choose pandoc + LaTeX templates when you need batch automation, strict template control—daily PDFs from many .md files, exact headers/footers and bibliography styles, CI integration. Browser conversion fits personal, occasional, need-result-now single-file delivery. Simple rule: repeat often + need precise layout control → pandoc; otherwise browser is usually cheaper.
Summary
Delivering Markdown as Word/PDF is structured format conversion. Avoid "copy rendered HTML" dirty paths; for occasional delivery use browser conversion, run lint on source first; for batch automation use pandoc. Handle images, long docs, and fonts upfront—and the output is ready to send.