Word Document Metadata: What Your DOCX Files Reveal and How to Strip It

People treat PDFs as the privacy risk and Word files as harmless drafts. That has it backwards. A .docx file carries more identity-bearing metadata than most PDFs, it updates itself every time you hit save, and it travels inside ZIP archives that people forward without thinking. If you share contracts, CVs, letters or reports as Word files, here is what goes along for the ride.

What is inside a .docx file

A .docx is not a single document. It is a ZIP archive containing XML parts, and you can prove this yourself: copy any Word file, rename the extension to .zip, and open it. Inside, among other parts, you will find:

• docProps/core.xml, the core properties. Author, last modified by, creation date, last print date, revision number and the raw time spent editing.
• docProps/app.xml, the application properties. These are the leaky ones: the exact version of Word that saved the file, the company registered in that copy of Office, the template the document was built from, and its full original path.
• docProps/custom.xml, if present, any custom properties a firm or template injected, sometimes client codes or matter numbers.
• word/document.xml, the body itself, plus comment and tracked-changes parts that most people never fully clear.

The app.xml part is why template metadata leaks so consistently. A CV built on a corporate template can carry the previous employer's company name and a path like C:\Users\jsmith\...\HR_Outreach_v7.docx into every application sent out. People have been identified this way.

The two things Word's own "remove" button misses

Word's Document Inspector, and the Inspect Document flow, clear the core properties. Two things survive:

Tracked changes and comments. Accepting all changes does not delete the record of who made them. Comments store the author as a name string, sometimes with an email, in separate parts. The reliable fix is to check the document for comments and revisions, and if in doubt, strip them in a proper metadata cleaner rather than trusting the UI.

Text in deleted-but-not-removed parts. A file that has been edited heavily keeps older XML parts until the file is rewritten. If someone deleted a paragraph last week, the residue can persist in a part a normal save does not always purge. Stripping metadata from a copy of the file, rather than re-saving in Word, is the safe path.

We go into the same problem in PDFs in our article on PDF metadata in invoices and contracts. Word and PDF leak differently, and you need both checks.

Practical scenarios where this bites

Job applications. A CV drafted at your current employer will name that employer in app.xml, along with the person's Windows account in the paths. Sending it as .docx to a recruiter discloses where you work.

Quotes and tenders. Firms reuse old quotes as templates. The client name from three quotes ago can sit in a custom property, and the template path can reveal internal folder names such as Lost_2025.

Legal and medical documents. Editing history, printed dates, total editing time and who touched the file last are all disclosable in disputes. That cuts both ways: your own files testify about you too.

If you routinely send documents to strangers, the checklist in our metadata checklist before sending applies to documents, not just images.

How to check a file before you send it

On this site, you can drop the .docx straight into the remover and read the full property list before cleaning: author, company, template, revision count, editing time and the application version. That review step matters. If the tool shows a company name you did not expect, you want to know before the recipient does.

Cleaning happens entirely in your browser. A .docx is read with the same ZIP handling your own operating system uses, the metadata parts are rebuilt without the identifying properties, and the cleaned file is reassembled locally. Nothing uploads, so sensitive documents never leave your machine, which is the only sane default for contracts and medical files. The cleaned file gets a SHA-256 hash so you can prove which version you sent.

If the file is going to a third party and you do not need them to edit it, the stronger move is to clean the .docx and then export a PDF, then clean the PDF too. That two-step leaves neither editable residue nor the PDF layer of author and producer strings.

The habit, in one line

Never send an original. Every file you clean is a copy, made in the browser, stripped, and downloaded fresh. Keep the original on your disk with its history intact for your own records, because editing history in a .docx can be useful evidence for you, and send the stripped copy. That one habit removes the whole class of problem.

Published 11 October 2026