Skip to content
← Utility Tools

DOCX to Markdown

Convert .docx to clean Markdown in your browser — nothing uploaded

DOCX to Markdown Converter (mammoth.js)

Migrating content from Word to a static-site generator, a wiki, or a docs platform is a recurring task and a chronically annoying one. Word's native XML format (the .docx zip with embedded XML parts) carries a lot of structure that Markdown does not need and a lot of styling that Markdown explicitly drops. The right conversion is structure-preserving and styling-shedding: keep the headings, lists, links, and tables; drop the font, color, and per-paragraph spacing overrides. mammoth.js is the well-tested library for exactly this transform, and this tool runs it in your browser so the document never leaves the tab.

What mammoth.js Preserves

Headings (Heading 1 through Heading 6 styles in Word map to # through ###### in Markdown), paragraphs, ordered and unordered lists (with nesting), hyperlinks, inline bold and italic, and inline code formatted with the Code character style or with a monospaced font. Basic tables are preserved as GitHub-flavored Markdown tables when they have a single header row and no merged cells. Images are extracted from the .docx and embedded inline as data URIs by default; an option re-emits them as external references if you want to handle the images separately in the destination platform.

What mammoth.js Drops

Direct character formatting beyond bold/italic/code (font family, font size, color, highlight) — these have no Markdown equivalent and are intentionally dropped. Page-level constructs (headers, footers, page numbers, page breaks, multi-column layouts) — same reason. Tracked changes and comments — the rendered output is the accepted, comment-free version; the tracked-changes history is not part of the Markdown output. Equations rendered with the Word equation editor become a placeholder; for documents with serious mathematical content, a dedicated Word-to-LaTeX or Word-to-MathML tool is a better fit.

Before you convert, take a look at who authored the file and when — the DOCX Metadata Inspector reads the core, app, and custom properties from a .docx in your browser.

Why a Custom Style Map Is Sometimes Worth It

mammoth.js uses a style-map system that lets you specify how named Word styles convert to Markdown. The default map covers all the standard Heading and List styles. For documents that use custom styles (a corporate template often has a "Callout" style or a "Code Block" style that the default map doesn't recognize), you can provide a custom map at conversion time. The tool exposes the standard map by default and an advanced panel for entering a custom style-map string — the same syntax mammoth.js accepts in its programmatic API. Most users never need this; for a one-off migration of a heavily-templated corpus it can be the difference between a clean output and one that needs hours of post-processing.

Browser-Only Conversion and the Privacy Posture

The whole conversion happens locally. mammoth.js is bundled into the page (about 493KB minified, loaded on demand the first time you convert a file). When you drop a .docx file in, it is read into a browser Blob via FileReader, parsed by mammoth.js as a zip archive, walked as XML, transformed to Markdown via the style map, and offered as a download. Nothing crosses the network. This matters for any document that contains internal information — personnel records, legal drafts, financial reports — where uploading the file to a server-side converter would be a small but real disclosure risk. The Network tab in your browser confirms no upload occurs.

Pair this with the rest of the UDT document-conversion cluster: DOCX Metadata Inspector for examining author, dates, and document properties before or after conversion, PDF to DOCX for the upstream PDF case, Markdown Preview for previewing the converted output, and HTML to Markdown for the HTML-source case.

Frequently Asked Questions

Is the .docx file uploaded anywhere during conversion?+
No. mammoth.js is bundled into the page and runs in your browser. The .docx file is read locally via FileReader, parsed in memory, and converted to Markdown without ever crossing the network. The Network tab in your browser developer tools confirms no upload while the tool runs.
What structure does the converter preserve?+
Headings (Heading 1–Heading 6), paragraphs, ordered and unordered lists (including nesting), hyperlinks, inline bold and italic, inline code, and basic tables (single header row, no merged cells). Images are extracted and embedded as data URIs by default. This covers roughly 95 percent of the structure in typical narrative documents.
What does it drop?+
Direct character formatting (font family, color, size, highlight) since Markdown has no equivalent; page-level constructs (headers, footers, page numbers, multi-column layouts); tracked changes (the output is the accepted version); comments; and Word-equation-editor equations (these become a placeholder). For documents that rely heavily on any of these, the conversion will not be lossless and post-editing will be needed.
Can I use a custom Word style map?+
Yes. The advanced panel accepts mammoth.js's standard style-map syntax — the same lines you would pass to the library's programmatic styleMap option. The default map covers the standard heading and list styles; the advanced map is useful when a corporate template uses custom-named styles that the default does not recognize.
How are images handled?+
Images embedded in the .docx are extracted automatically. By default they are emitted as data URIs inline in the Markdown, which produces a self-contained file that works anywhere Markdown renders. An option switches to external-reference mode, which emits image filenames in the Markdown and provides a zip download of the extracted images for separate handling — useful when the destination platform handles images via a separate upload step.
Does it handle tables with merged cells?+
Not natively — GitHub-flavored Markdown tables do not support merged cells. mammoth.js will produce a best-effort table that approximates the layout, but cells that span multiple rows or columns in the source will be expanded to fill each affected position individually. For documents with complex tables, post-editing or using a different target format (HTML) is the right answer.
Are tracked changes preserved?+
No. The conversion uses the rendered (accepted) version of the document; tracked changes that have not been accepted or rejected are treated as if they were accepted. If the tracked-change history is part of what you need to preserve, this tool is not the right fit — export the document with revisions visible from Word first, or use a tool that exposes the revision history explicitly.
What is the file-size ceiling?+
There is no hard cap because the work runs in your browser. Files up to tens of megabytes work fine on a modern laptop. Very large documents with hundreds of embedded images may stall on a slower device because of the inline data-URI expansion — use the external-reference mode for those cases.

Built by Derek Giordano · Part of Ultimate Design Tools

Privacy Policy · Terms of Service