How to convert Markdown to Word (.docx)
Three reliable ways to turn a Markdown file into an editable Word document, what each preserves, and when a link beats a .docx entirely.
You wrote something in Markdown, clean and fast, and now someone needs it as a Word document. Maybe a teacher wants .docx, a client only edits in Word, or a submission form demands it. The good news: converting Markdown to an editable Word file is straightforward, and the text survives well. Here are the three reliable ways, what each keeps, and one question worth asking before you convert anything.
Method 1: Pandoc (the dependable one)
Pandoc is a free command-line converter and the standard tool for this. One command:
pandoc input.md -o output.docx
That produces an editable .docx with your headings as Word heading styles, lists as lists, bold and italic intact, code blocks formatted, and Markdown tables as real Word tables. It handles the full range of Markdown plus extensions, footnotes, math, and more. If you convert often, Pandoc is the one to learn; it is consistent and scriptable.
Method 2: Styled output with a reference doc
Default Pandoc output is plain. To make it match your house style, use a reference document. Generate one, edit its styles in Word, then convert against it:
# 1. create a reference doc pandoc -o reference.docx --print-default-data-file reference.docx # 2. open reference.docx in Word, set fonts / heading # sizes / spacing, save # 3. convert using your styled reference pandoc input.md --reference-doc=reference.docx -o output.docx
Now every conversion inherits your fonts, heading sizes, and spacing. This is the cleanest path to branded, consistent Word output, set the styling once, reuse it forever.
Method 3: No-install options
If you do not want a command line, a few paths exist: web-based Markdown-to-Word converters (fine for a one-off, quality varies), and editor exporters, VS Code extensions and Obsidian plugins can export .docx directly. These are convenient for a single document; for anything repeatable or styled, Pandoc still wins.
What converts cleanly, and what doesn't
The honest picture of any Markdown-to-.docx conversion:
Survives well Drops or flattens ----------------------------------------------------- headings -> Word styles interactive embeds lists, tables live charts / dashboards bold / italic / code links to dynamic content footnotes, math anything web-native
The rule of thumb: plain prose and structure convert cleanly; web behaviors do not. That is not a Pandoc limitation, it is the nature of .docx, which is a fixed document format with no concept of live or interactive content. If your Markdown is text, headings, and tables, the Word file will look right. If it leaned on embeds or live data, those parts flatten.
The question before you convert: do you need a file?
People convert to .docx out of habit. The real requirement is usually one of two things: someone must edit it in Word, or a process demands a file. Only those actually need a Word document.
If the receiver just needs to read or comment, a shared web link does the job better. It stays the current version instead of forking into doc_final_v3.docx across inboxes, keeps any embedded chart or media live, and opens on any device. This is the idea behind the document is a link: you hand around a URL, and the file is a derivative you make only when required.
This is how Plain works for documents. Your doc is Markdown rendered as a web page, shared as a link, and when a receiver genuinely needs Word, Plain exports .docx as a downgrade, the same fixed-format conversion Pandoc performs. The difference is that the file is no longer your primary artifact; the link is, and the export is a fallback. Because the source stays Markdown, the document also diffs cleanly when you revise it.
The short version
To convert Markdown to Word: use pandoc input.md -o output.docx for a clean editable file, add a reference doc if you want consistent styling, or use a web converter / editor plugin for a quick one-off. Expect text, headings, and tables to survive and web-native content to flatten. And before you convert, ask whether the receiver needs an editable file or just needs to read it, because if it is the latter, a link beats a .docx on every count except one: being a file.