Settings

A .docx is a zip archive

The first four bytes of a .docx are 50 4B 03 04: the two letters PK, then 03 04. That is the local file header signature, the four bytes every zip archive begins with. Copy the file, rename the copy to .zip and open it, and you get a folder of XML parts. A short document built for this page unpacks to nine of them:

[Content_Types].xml _rels/.rels docProps/app.xml docProps/core.xml word/_rels/document.xml.rels word/comments.xml word/document.xml word/media/image1.jpeg word/settings.xml

The words you can see on the page are in word/document.xml. Almost everything on this page is in one of the other eight.

docProps: who, when, and for how long

docProps/core.xml is a small file with a handful of elements in it, and these are the ones that carry a person:

  • dc:creator — the account name on the machine where the document was first made. Not who typed today. Who started it.
  • cp:lastModifiedBy — the account that saved it last. When this differs from dc:creator, the document has changed hands, and both names are in the file.
  • dcterms:created and dcterms:modified — timestamps, to the minute, in UTC.
  • cp:revision — how many times it has been saved. The test file says 17.
  • dc:title, which is frequently an earlier filename, along with dc:subject, dc:description and cp:keywords.

docProps/app.xml holds a second set. TotalTime is the cumulative minutes the document has been open for editing: the test file says 288, which X-RAY prints as 4 hours 48 minutes. Company is whatever was typed into the copy of Word that made it. Template names the .dotx it was built from, which tends to say more about where a document really came from than anything in the text does.

Tracked changes are not a display setting

When track changes is on, a deletion does not remove anything. The run is wrapped in a w:del element and its text element is renamed from w:t to w:delText. The words are still there, in order, in word/document.xml. Turning revision marks off in Word only stops drawing them.

<w:del w:id="2" w:author="Marcus Hollis" w:date="2026-02-27T11:06:00Z"> <w:r><w:delText>48,000</w:delText></w:r> </w:del> <w:ins w:id="3" w:author="Marcus Hollis" w:date="2026-02-27T11:06:00Z"> <w:r><w:t>32,000</w:t></w:r> </w:ins>

Run that document through X-RAY and it comes back with the figure the document used to say, and the name of the person who changed it. Insertions are the mirror image, in w:ins, and there is a matching set for formatting: w:rPrChange, w:pPrChange and their table equivalents record what the formatting was before somebody altered it.

Comments, sessions, images, and text that is only hidden

Comments live in their own part. word/comments.xml holds each one as a w:comment with w:author, w:initials and w:date on it, and the body of the comment as ordinary paragraphs. Modern Word adds more parts beside it: commentsExtended.xml, commentsIds.xml, threadedComments.xml and people.xml, the last of which is a list of everyone who commented.

word/settings.xml ties files together. Inside it is a w:rsids block listing revision-save identifiers, and the same values appear as w:rsidR and w:rsidRDefault attributes on the paragraphs and runs they belong to. One is written per editing session, so two documents that share rsid values were worked on in the same sitting. They survive an edit that changes every visible word.

Pictures keep their own metadata. A photograph pasted into a document is stored under word/media/ as its own file, and it is stored as-is. A JPEG carrying GPS coordinates was placed into the test document; pulled back out of the zip it was byte-for-byte identical to the original, and reading it gave the same latitude and longitude. A document with no location data of its own can still contain a photograph that has some. What is in a photo file covers that side of it.

Hidden is not deleted. A run marked <w:vanish/> in its run properties is not displayed and does not print, but it is an ordinary run holding ordinary text. The test document has one: an internal note about the real exposure in a settlement. Any library that reads paragraph text reads it straight out, because there is nothing to defeat — the text is there and a formatting flag says do not draw it.

Why accepting all changes is not enough

Accepting every change is an edit to one part. It unwraps each w:ins, removes each w:del and its w:delText, and drops the formatting-change records. Done to the test document, the figure 48,000 disappears and 32,000 stays, exactly as it should.

docProps/core.xml is a different part and nothing in that operation touches it. After the accept, dc:creator still reads Priya Raman and cp:revision still reads 17. The redlines are gone and the names are not.

This is the general shape of the problem. The document is a package of parts, and cleaning one part leaves the others as they were. Comments are a separate part. The rsids are a separate part. The photograph is a separate file inside the zip.

What to do before you send one

Read it first. X-RAY unpacks the zip in the browser tab and reports what it finds: the author and the last person to save it, the revision count, the editing time, the template, every passage deleted under tracked changes with the name of whoever deleted it, every comment with its author, and any absolute file paths left in the XML. It reports; it does not change the file.

Then clean it. DOCSCRUB is the Word-only pass: it deletes the comment parts outright, accepts the tracked changes, empties dc:creator, cp:lastModifiedBy and dc:title, sets cp:revision to 1, removes the created and modified timestamps, empties Company and Template and sets TotalTime to 0. It cleans headers, footers, footnotes and endnotes the same way as the body, because tracked deletions hide in those too.

Or use the wider one. SCRUB does Word, Excel, PowerPoint and PDF. It rewrites docProps/core.xml from scratch rather than editing it, so nothing survives in a field nobody thought to check, and it is the one that removes the rsids: every attribute whose name starts with rsid, plus the w:rsids block, w:proofState and w:attachedTemplate in word/settings.xml. On the test document it found and removed two rsid attributes that DOCSCRUB left alone.

What this is, and what it is not

Neither cleaner removes text marked hidden. A run with w:vanish in its properties survives both DOCSCRUB and SCRUB, and X-RAY does not report it either. The text is genuinely in the document and genuinely invisible on screen. Until that changes, the way to find it is to turn on Show Hidden Text in Word, or to unzip the file and search word/document.xml for vanish.

The photograph inside the document is not examined. Neither cleaner touches word/media/, and X-RAY does not read the EXIF of an image it finds inside a .docx. If a document contains photographs that matter, strip them with CLOAK before they go into the document, or check them after by unzipping the file.

Reporting and removing are different jobs. X-RAY changes nothing; it is for finding out what a file received from somebody else is carrying. DOCSCRUB and SCRUB change the file and hand back a copy. Run the reader after the cleaner if you want to see what is left rather than trust that the pass worked.

Word's own Document Inspector is worth running, and is not the whole job. It removes most of this. Embedded objects, some custom XML parts and author names recorded inside earlier revisions can survive it, and it has to be run again after any save that puts them back.

Cleaning metadata is not redaction. None of this removes anything a reader can see. Text that should not be disclosed has to come out of the document, not be covered over or coloured white; SEAL is the tool for taking content out of a PDF for real.

Questions people ask

How do I see inside a .docx myself?

Copy the file, rename the copy so it ends in .zip, and open it. You get a folder of XML parts. The text is in word/document.xml, the author and dates in docProps/core.xml, the editing time and company in docProps/app.xml, and any comments in word/comments.xml. It is plain text and any editor will show it.

Can someone read what I deleted from a Word document?

If track changes was on and the changes were never accepted, yes. The deleted words stay in word/document.xml inside w:del elements, marked with the name and the timestamp of whoever removed them. Turning revision marks off in Word hides them on screen and leaves them in the file.

Does accepting all changes clean the document?

It removes the redlines and nothing else. The author name, the account that saved it last, the revision count, the editing time, the company and the template are in the document properties, which are separate parts of the package that the accept never touches.

What are the rsid values in the file?

Revision-save identifiers. Word writes one per editing session and stamps it on the runs and paragraphs edited in that session, then lists them in word/settings.xml. Two documents that share those values were edited in the same sitting, which is a link between files that nothing visible in either one shows. SCRUB removes them; DOCSCRUB does not.

Is text hidden with hidden formatting safe to leave in?

No. It is ordinary text with a flag on it saying do not draw. It is in the file, it comes out of any tool that reads the XML, and anyone who switches on Show Hidden Text sees it in Word. Delete it rather than hiding it.

Does converting to PDF fix all of this?

It deals with tracked changes, and with hidden text unless you have asked Word to print hidden text, because what is printed is what is left. It does not deal with the properties: the PDF has its own author, title and producer fields, which is a fresh set of the same problem. SCRUB clears those as well. A PDF also brings its own trouble, mainly that a black rectangle drawn over text does not remove the text.

Related tools