Word to Markdown: A Real Mapping, Not an Educated Guess
Rename any .docx file to .zip and open it. Inside you'll find a folder tree:
word/document.xml holds the content, word/styles.xml defines the styles,
word/media/ holds every embedded image, and footnotes.xml and
comments.xml sit alongside them. A .docx isn't a picture of a page. It's a structured XML
document in a zip container.
That matters enormously for conversion quality. Turning a PDF into Markdown means inferring
structure from font sizes and coordinates. Turning Word into Markdown means reading structure
that's already declared. A paragraph tagged w:pStyle="Heading2" becomes ##
because the file literally says it's a level-two heading. This is why a docx to Markdown
converter generally produces cleaner output than the same document exported to PDF and
converted from there. Upload a file above and see — free, no sign-up, 50 MB limit, nothing stored.
Styles vs Direct Formatting: The One Thing That Decides Your Output
There are two ways to make text look like a heading in Word, and they are not equivalent.
Applying a style — clicking "Heading 1" in the ribbon — writes a semantic label into
the XML. The converter reads that label and emits #. Direct formatting —
selecting the line, bumping it to 16pt, hitting bold — writes only visual properties. There is no
"this is a heading" anywhere in the file, because as far as Word is concerned it's a normal paragraph
that happens to be big and bold. It converts to a bold line of body text, and your document arrives in
Markdown as one flat wall with no sections.
If your output looks structurally empty, this is almost always why, and the fix lives in the source document. Open the Styles pane, apply real heading styles to your section titles, save, convert again. Five minutes of work that transforms the result — and it makes the Word document better too, since the navigation pane and auto-generated table of contents start working.
Tracked Changes, Comments, and Footnotes
Most real Word documents have been through several people, and they carry the evidence. Here's what happens to each layer:
- Tracked changes live in the XML as
w:insandw:delruns wrapped around the affected text. Conversion resolves the document to its accepted state: insertions are kept, deletions dropped. If a legal team's revision history matters to you, that history is gone — convert before and after separately and diff the two outputs instead. - Comments sit in a separate part of the archive and are anchored to ranges in the body. They aren't body text, so they don't appear in the converted output. Useful when the marginal chatter is noise, a problem if the review comments are what you wanted to summarise.
- Footnotes and endnotes also live in their own parts. They generally come through as text but detached from their exact anchor point, since Markdown has no native footnote syntax in the base spec. Check the tail of the output if citations matter.
- Headers, footers, and page numbers are dropped. Markdown has no pages, and running furniture is noise in an AI context anyway.
- Fields — auto-numbering, cross-references, a generated table of contents — convert to whatever their last-rendered value was, not to live references.
The safe habit: Review → Accept All Changes, then Save As a copy, then convert. You know exactly what text you're working with.
Tables, Images, and Where Markdown Runs Out of Room
Word tables are genuine grids — rows and cells declared in XML, not columns of text that happen to line up visually. So they map to Markdown pipe tables cleanly, which is the strongest single argument for picking Markdown over flat text when your document has any tabular content at all.
The exception is merged cells. Markdown tables have no rowspan or colspan, so a header cell spanning three columns has to be flattened somehow, and complex nested tables come out approximated rather than exact. Simple grids convert perfectly; invoice-style layouts with merged banner rows need a glance before you trust them.
Embedded images are a harder limit. The pixels are in word/media/, but text conversion
produces text — an image reference, not the picture, and definitely not the words inside it. If your
document's key diagram is a screenshot of a table, that content is invisible to conversion. Export the
image separately and run it through image to Markdown,
or better, rebuild it as a real Word table before converting.
.doc and .docx Are Not the Same Format
They share three letters and almost nothing else. .docx arrived with Office 2007 and is
Open XML — the zip-of-XML described above, openly specified and straightforward to parse. The legacy
.doc is a binary compound file: a miniature filesystem of streams, reverse-engineered for
decades, with structures that vary by the Word version that wrote them.
Practical upshot: .docx conversion is reliable, .doc conversion is best-effort. If you're getting odd results from an old file, open it in Word or LibreOffice, Save As .docx, and convert that instead. It costs thirty seconds and removes an entire category of problem. The same applies to RTF files, which are older still and carry even less semantic structure.
Markdown or Plain Text? Pick by What You're Doing Next
Choose Markdown when the shape of the document carries meaning. A requirements spec with nested numbered clauses, a policy with a defined section hierarchy, a proposal full of pricing tables, technical documentation with code samples — in every one of those, structure is information. Ask a model about "the deliverables in section 3" and it needs section 3 to exist as a unit.
Choose Word to plain text when you want the words and nothing else — feeding a classifier, building embeddings, indexing for search, or diffing two revisions line by line. Markdown syntax is dead weight in those pipelines.
The toggle at the top of this page swaps between the two and carries your selected file across, so you can produce both and compare without uploading twice. The token counter under the output tells you what the result will cost in a model's context window before you paste it anywhere.
Frequently Asked Questions
How do I convert a DOCX to Markdown?
Upload the file above and copy the Markdown out, or download it as .md. Works with .docx and older .doc, 50 MB per file, free and no account needed. Heading styles map to # levels, bold and italic survive as ** and *, and lists keep their nesting.
Will my headings actually come through?
Only if they were real headings. A document where the author used the Heading 1 and Heading 2 styles converts into a clean # and ## outline. A document where someone made text big and bold by hand has no heading information stored in it at all — visually identical in Word, and it converts to ordinary paragraphs, because there is nothing there to read.
Is this good enough for moving Word docs into a docs site?
It gets you most of the way. Prose, headings, lists and simple tables convert cleanly enough to commit. What needs a human pass afterwards: embedded images, complex merged-cell tables, equations, and any custom styling that carried meaning by convention rather than by structure.
What about equations and embedded images?
Equations do not survive as LaTeX or MathML and images are not extracted into an asset folder — the output is text and structure. For documents where the maths is the content, expect to re-author those blocks. It is worth knowing before you convert a hundred files and discover it on file ninety.
Word to Markdown or Word to text?
Markdown if the document has an outline worth keeping, or if it is heading somewhere that renders Markdown — a repo, a wiki, an LLM prompt. Plain text if the destination parses words rather than formatting, which covers most search indexing and embedding pipelines.
The Rest of the Toolkit
Word is one of thirteen formats handled here. File2Txt accepts any of them from one upload, or jump straight to PDF to Markdown, PowerPoint to Markdown for decks, or Excel to Markdown for spreadsheets. If you've got a folder of mixed documents, zip it and use ZIP to Markdown to convert everything inside in one pass.
For code and web content there's the GitHub to text converter, a GitLab equivalent, a local directory converter, and Web2Txt for scraping pages into Markdown. The guide to preparing documents for LLMs goes deeper on why any of this is worth doing.
Repo2Txt is built and maintained by v12hero, an independent developer building privacy-first native and web apps.