Convert Markdown to Word
Markdown is written by people who like plain text and read by people who want a document. This conversion is the handover — and it is a real one, in that a `##` becomes a Word Heading 2 rather than a line that happens to be larger.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeDrop your MD file here, or click to browse
Up to 50 MB. Deleted automatically after 30 minutes.
What it does
- Headings become real Word heading styles, so the navigation pane works
- Pipe tables become actual Word tables, not tab-separated text
- Bold, italic, links, lists, quotes and code blocks all carried across
- No watermark and no sign-up
How to use Markdown to Word
- 1
Add the Markdown
A .md file from a repository, a notes app, or a static site. Standard Markdown is what is understood; extensions that only one tool implements may come through as literal characters.
- 2
Convert
The Markdown is parsed into a document model — headings, emphasis, lists, tables, code — and that model is written out as OpenXML.
- 3
Open the navigation pane
In Word, View then Navigation Pane. Your heading structure should be sitting there as an outline. That is the quickest confirmation that the conversion produced a structured document rather than styled text.
How it works
The file is parsed as Markdown into a document model — a tree of headings, paragraphs, emphasis runs, lists, tables and code blocks — and that model is written out as OpenXML, which is what a .docx contains.
The important word is parsed. A converter that skipped that step and treated
the file as plain text would produce something that opens in Word and is full of
punctuation, and this is a common enough outcome that it is worth verifying
rather than trusting. Unzipping a converted file here and reading the XML shows
Heading1 and Heading2 style references and a genuine table element, not
formatted paragraphs imitating them.
Why this conversion keeps being needed
Markdown won among people who write in editors and store their work in version control. It diffs cleanly, it has no proprietary format, and it stays readable when the tool that made it is gone.
Word won everywhere a document has to be reviewed, commented on, tracked and signed off. Legal, procurement, compliance and most of the people who approve things work in it, and they are not going to review a pull request.
So the same document has to exist in both worlds — written in one, approved in the other. That is what this is for.
Getting a good result
Use one top-level heading. Word's outline assumes a single document title
with sections beneath it. Several # headings produce a flat structure.
Keep tables simple. Pipe tables map cleanly. Tables where cells contain lists or line breaks do not, because Markdown itself has no way to express that.
Convert last, not first. Once the file is a .docx, changes belong in the .docx — converting again overwrites whatever the reviewers did. The handover is one-directional in practice, so make it late.
When PDF is the better target
If nobody is going to edit the document, convert straight to PDF instead. You get identical rendering everywhere, no font substitution, and no chance of an accidental edit, and the heading structure still becomes PDF bookmarks. Choose .docx specifically when you want tracked changes and comments back.
Examples
A release-notes file
Verified by unzipping the result and reading its XML: one Heading 1, one Heading 2, a real table element with the cell values in it, bold and italic runs, and a numbered list. The size ratio is not a warning sign — almost all of a .docx is style and structure definitions.
A README going into a specification pack
Link addresses are preserved as document relationships, so they stay clickable rather than collapsing to their text. This is the difference between a converted document and a pasted one — pasting Markdown into Word gives you the asterisks.
Frequently asked questions
Does this actually understand Markdown, or is it just treating it as text?
It parses it. That distinction is worth checking rather than assuming, because a converter that treats Markdown as plain text produces a document full of hash symbols and asterisks, which looks like a bug. Here a `#` line arrives as Heading 1, `**bold**` as a bold run, `- item` as a list item, and a pipe table as a table object.
Why do heading styles matter more than the text just looking bigger?
Because Word builds things out of them. The navigation pane, the automatic table of contents, cross-references, PDF bookmarks on export, and accessible reading order for screen readers are all driven by heading styles rather than by font size. A document where the headings are merely large text looks right and behaves like an undifferentiated wall of paragraphs.
What does not come through?
Anything outside standard Markdown. Front matter blocks at the top of the file appear as literal text; footnote syntax, task-list checkboxes, admonition blocks and other flavor-specific extensions are not universally understood. Raw HTML embedded in the Markdown is unreliable. Images referenced by relative path cannot be fetched, because only the .md file is uploaded.
How do code blocks look?
Fenced blocks are preserved as blocks with their line breaks and indentation intact, which is the part that matters — code that has been reflowed as prose is useless. Syntax highlighting is not carried across, since the colors were never in the Markdown; they were added by whatever was displaying it.