Extracting Text from Word Documents: What a .docx Really Contains

A folder of Word documents has to become something a program can read: rows in a database, input to a search index, chunks for a language model, or plain text for a diff. Opening each one and copying by hand does not scale, and opening a .docx in a text editor shows binary noise. This guide explains what is inside the file, what you lose when you extract text, and when plain text is the right target versus HTML.

Since Word 2007, a .docx has been an Open Packaging Convention container: a ZIP file holding XML parts. Rename one to .zip, open it, and the structure is plain to see.

Two consequences matter. Text extraction is an XML problem, not a reverse-engineering problem, which is why it can run reliably in a browser. And a .doc from Word 97–2003 is a completely different, genuinely binary format — those must be converted to .docx in Word or LibreOffice first.

Word splits a sentence into runs whenever formatting changes. A line reading Total: 42 unitswhere only the number is bold becomes three separate runs in the XML. A naive extractor that concatenates text nodes without understanding paragraph boundaries produces one of two classic failures: everything run together into a single line, or a line break inserted in the middle of every formatted phrase.

Spell-check and tracked-change markers make it worse — Word sometimes splits a single word across runs mid-spelling, so careless extraction yields doc ument. A correct extractor walks paragraphs, joins runs inside each one, and emits a break only at real paragraph and table-cell boundaries. This is what separates a usable result from one you spend an afternoon cleaning.

The two tools answer different downstream needs, and picking the wrong one means either cleaning markup you did not want or trying to reconstruct structure you already had.

• Word to Text gives .txt: paragraphs, no markup. Right for full-text search indexing, word counts, diffing two revisions, feeding a model, or any pipeline where formatting is noise. Headings become ordinary lines, so document structure is gone.
• Word to HTML keeps semantic structure — headings as h1 to h6, lists as ul and ol, tables as real tables, bold and italic preserved. Right for publishing to a CMS, converting to Markdown afterwards, or any case where knowing what is a heading matters. Note this is semantic HTML, not a pixel-faithful reproduction of the Word layout.

A useful rule: if the next step is a machine deciding what the document is about, take text. If the next step involves a human reading it or a system that cares about hierarchy, take HTML.

• Page layout. A DOCX has no fixed pages — Word repaginates on the fly according to the printer driver. There are no page numbers to extract because they do not exist in the file.
• Headers, footers and footnotes live in separate XML parts and are normally excluded from body extraction. If a footnote carries the citation you need, check for it explicitly.
• Images are separate files in the archive. Text extraction skips them; to retrieve them, treat the document as a ZIP and pull word/media/.
• Text boxes and SmartArt sit in drawing parts outside the main paragraph flow and are frequently missed by every extractor, including commercial ones.
• Tracked changes. Depending on the extractor, deleted text may or may not appear. Accept or reject all changes in Word before extracting anything that matters.

For a large batch, the practical route is ZIP everything, extract, then process. Our ZIP Extractor lists an archive's contents in the browser so you can confirm what you have before pulling files out. If some of the documents are PDFs rather than DOCX, PDF to TXT covers those — but with one important difference: it reads the PDF's text layer, and a scanned PDF has none, so it returns nothing. That is not a failure of the tool; it means the file needs OCR first. Going the other direction, TXT to PDF turns extracted or generated text back into a shareable document.