Opening a DOCX without Word, and what is hiding inside it

The .docx extension has been a zip file since 2007. Not "like" a zip file, actually one. Copy a document, rename it to report.zip, and any unzip tool will open it and show you a folder tree of XML.

That single design decision is why a web page can read a Word document at all, and it is also why Word documents give away more than their authors expect.

What is in the box

Unzip a typical document and you get something close to this:

The text itself is not stored as a page. It is stored as structure: this is a paragraph using the style Heading 1, this run of characters is bold, this is a table with these cells. Where any of it physically lands is decided when something lays it out.

That is why a DOCX viewer in a browser can show you a readable document without Word installed. It is reading the same XML Word reads and applying the same style definitions. It is also why the rendering is close but not pixel-identical: Word's line-breaking and hyphenation are its own, and nothing else reproduces them exactly.

The metadata nobody remembers is there

Open docProps/core.xml in any text editor and you will find something like this:

<dc:creator>Priya Nair</dc:creator>
<cp:lastModifiedBy>a.kumar</cp:lastModifiedBy>
<cp:revision>47</cp:revision>
<dcterms:created>2026-03-02T09:14:00Z</dcterms:created>

And in docProps/app.xml, a TotalTime field counting the minutes the document has been open for editing across its whole life.

None of this is visible in the document. All of it is copied when you send the file.

If you want to see what a specific file is carrying, Word lists those fields under File, then Info, and Check for Issues, then Inspect Document removes them. You can also rename a copy to .zip and open the two files in its docProps folder.

Tracked changes are not deletions

This one has produced actual news stories.

When change tracking is on, deleted text is not removed from document.xml. It is wrapped in a <w:del> element and hidden from the current view. The characters are still in the file. Anyone who turns tracking display on, or who unzips the document and reads the XML, can read every sentence that was cut.

The same applies to comments. Resolving a comment thread does not delete it, and comments.xml keeps the text and the names.

Accepting all changes and deleting all comments removes them. Saving over the file without doing that does not.

Getting the text out cleanly

Once you know the text lives in XML, the conversion options make more sense as a set of trade-offs about how much structure you want to keep.

• DOCX to plain text keeps the words and nothing else. No styles, no metadata, no tracked changes, no comments. This is the bluntest and most reliable way to reduce a document to its content.
• DOCX to HTML keeps headings, lists, tables, bold and italic, and maps them onto real HTML elements. This is what you want when the text is going onto a web page, because you keep the structure and lose the Word-specific markup that otherwise arrives as a mess of inline styles.
• DOCX to Markdown keeps the same structure as plain, diffable text. Useful when the document is going into a repository or anywhere a future version needs to be compared against this one.

All three drop docProps entirely, because none of the target formats has anywhere to put it. Converting is therefore a side-effect-free way of removing history: what comes out is the text you can see and nothing you cannot.

A checklist before sending a document out

1. Accept or reject all tracked changes. Not "hide" them.
2. Delete resolved comments. Resolving is not deleting.
3. Check the author fields, especially if the file started life as someone else's template.
4. Consider whether they need a DOCX at all. If they are not going to edit it, a PDF or plain text carries far less.