Pulling Text Out of .docx Files Without Installing Word

Pasting text from Microsoft Word into a CMS is a small interface problem with a big history. The text in your Word document is not just letters - it carries a forest of invisible markup: font choices, font sizes, paragraph spacing rules, list styles, custom Word-specific formatting commands, and sometimes embedded zero-width characters that make spell checkers unhappy. When you paste that text into a CMS rich-text editor, all of it comes along. The result is content that looks slightly off, with mysterious extra spacing or weird font choices, and that triggers formatting bugs when displayed on the rendered site. Every CMS team I have worked with has had a "the marketing team is pasting from Word again" Slack channel.

The fix is to strip the Word formatting before pasting. The Word to Text tool does this by extracting only the meaningful content from the .docx file, dropping everything else. Plain text mode gives you bare words and paragraph breaks. HTML mode gives you semantic structure (headings, lists, bold, italic) without the Word-specific cruft.

How .docx is structured (briefly)

A .docx file is a ZIP archive containing XML files that describe the document content, styling, and metadata. The content lives in word/document.xml, which is a stream of paragraph elements (w:p) containing runs of text (w:r) with formatting properties. The styling lives in separate XML files that the content references by name. Images and embedded objects live in subdirectories.

The Toolium tool uses mammoth.js, a JavaScript library specifically designed for converting .docx files to plain text or clean HTML. Mammoth understands the .docx structure, walks the content stream, and produces output that preserves the structural meaning (this is a heading, this is a list, this is a paragraph) without preserving the visual styling (which would be useless without Word's rendering engine to apply it).

Plain text vs HTML output

Plain text mode produces unformatted text. Headings become regular paragraphs separated by blank lines. List items get prefixed with their bullet or numbering character. Tables get flattened with tab separators. Bold and italic markers are dropped entirely. This is the output you want when you need to pipe content into something that does not handle markup at all - a search index, a plain-text email, a script that does NLP.

HTML mode produces clean semantic HTML. Headings become h1 through h6. Paragraphs become p. Lists become ul/ol. Bold and italic become strong and em. Links are preserved. The HTML is "clean" in the sense that it has no inline styles, no class attributes pointing to Word styles, no span elements wrapping every run of text. It is the kind of HTML you would write by hand if you were transcribing the document into a CMS.

For pasting into a CMS, HTML mode is usually what you want. Most modern CMS rich-text editors accept HTML on paste and apply their own styling. The clean output from mammoth converts cleanly without bringing Word's quirks along.

What gets dropped

Some things in a Word document have no plain-text or semantic-HTML equivalent and get dropped on conversion:

• Images. They are not text. If you need the images, extract them separately (open the .docx as a ZIP and look in the word/media/ folder).
• Charts. Word stores charts as embedded objects with their own internal format. Mammoth does not extract these as anything useful.
• Equations. Stored as embedded objects. The conversion produces a placeholder or nothing.
• Comments. Excluded from the main output. If you need them, they live in word/comments.xml inside the .docx.
• Tracked changes. The conversion produces the "accepted" version of the document - whatever the current visible text is - rather than the markup showing what was changed.
• Section properties. Headers, footers, page numbers, page breaks - these are structural to Word and have no semantic meaning in HTML.

The .doc format problem

If your file extension is .doc (not .docx), you have an older format that mammoth and most browser-based tools cannot read. The .doc format is a binary blob (the legacy Word format from before 2007) that needs proprietary parsing code.

The fix is to open the file in Word, LibreOffice, or Google Docs, and save as .docx. Word does this automatically on save in recent versions. LibreOffice has "Save As" with format choice. Then the Toolium tool can read the result.

Google Docs files

Google Docs uses an internal format that is not .docx. To get a .docx from Google Docs, use File > Download > Microsoft Word (.docx). Google does the conversion server-side and gives you a real .docx file that mammoth can read.

The word-count question

The Toolium tool shows word count and character count alongside the extracted text. These counts match what Microsoft Word produces for the same content within a small margin - the differences are usually around hyphenated words (which Word sometimes counts as one and sometimes as two) and around abbreviations with periods (which affect sentence counting more than word counting).

For more detailed text analytics, use the dedicated Word Counter tool, which also shows sentences, paragraphs, reading time, and handles CJK languages where spaces are not used between words.

Privacy

Mammoth runs in your browser. The .docx file is read from a local File object and parsed in JavaScript. No upload occurs. If you are extracting text from a contract, an HR document, a confidential report, the file does not leave your computer.