Remove metadata from a Word document

What we remove

• Tracked changes. Deleted text is removed; inserted text is kept as ordinary content, without the author and date wrapper. Formatting-change and move markers are cleared the same way — they carry an author name too, not just insertions and deletions. This is the one that ends careers.
• Comments, including the author names and timestamps on every thread.
• Core properties — creator, last modified by, revision count, last-printed date, created and modified dates, title, subject, description, category, content status and keywords.
• Extended properties — company, manager, template name, total editing time, and the hyperlink base URL.
• Custom properties, which often carry internal project or client codenames.
• The embedded thumbnail, a preview image of the first page generated when the file was saved.
• Revision session identifiers, which fingerprint editing sessions and can link separate documents to each other.

What we deliberately keep

• Every paragraph, style and theme in the document body — styles.xml, theme.xml and the content itself are untouched.
• Embedded fonts and images, copied through exactly as they were.
• Accepted text from a resolved tracked change — only the deleted text and the author/date wrapper around it are removed.

What a real dump looks like

A .docx file is a ZIP archive — rename one to .zip and you can open it directly. Inside, docProps/core.xml holds creator, last-modified-by and dates; docProps/app.xml holds company, manager and total editing time; and if track changes was ever used, word/document.xml contains <w:ins> and <w:del> elements with an author name and timestamp attribute on every single edit — which is why a document that looks finished can still name everyone who touched it and when, buried in markup nobody reads directly.

The package structure, the properties schema, and the tracked-changes markup are all defined in ECMA-376, the Office Open XML standard — free to download, and the same document Word, LibreOffice and Google Docs all implement against when reading or writing a .docx file.

The thumbnail nobody thinks to check

Some .docx files carry docProps/thumbnail.jpeg (or .emf) — a rendered preview of the first page, embedded so file browsers and "recent documents" lists can show a thumbnail without opening the file. It's a genuine image, not text, so text-focused property tools never look for it, and it can keep showing a page's contents even after that page has been edited, redacted or replaced in the document body itself. We drop the whole part rather than trying to redact it, since a thumbnail with the sensitive part blacked out is still a thumbnail someone generated from an unredacted original.

The extended properties carry one more field worth knowing about: HyperlinkBase, a base URL that relative hyperlinks in the document resolve against. On a document built from a company template, it can point at an internal server or intranet path — infrastructure detail with no reason to leave the building alongside a document that does.

What survives common editors

"Accept All Changes" in Word removes the visual markup but doesn't touch the revision session identifiers in settings.xml unless you separately run Word's own Document Inspector — the tracked-change history can be gone from the page while a fingerprint of the editing session remains in the file. Converting to PDF strips almost everything, since PDF has no concept of a Word comment thread, but the core properties often get copied across into the PDF's own Info dictionary by the conversion step. Templates are a quiet, recurring leak: a company template with the founder's name hardcoded into core.xml stamps every document created from it, forever, until someone edits the template itself.

Why we rebuild the archive instead of editing it

A .docx is a ZIP archive with compressed, length-prefixed entries — editing the XML for one part in place would leave every entry after it pointing at the wrong offset, corrupting the file. So each part is read, the ones that need changing are rewritten, and the whole archive is reassembled from scratch. The tradeoff is the one PDF and the other Office formats share: this is a genuine rebuild, not a byte-level copy, so we don't offer the same before-and-after hash comparison the image formats get. What we do offer is the same list you see here: exactly which parts changed and why, not just a promise that cleaning happened.

Cleaning something else?

The same properties and tracked-change risk apply to Excel spreadsheets and PowerPoint decks from the same source — check those too. A PDF export of the same document carries its own separate copy of the metadata.