What is hidden in a Word document

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:

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.

Who edited this document, and can you trust the answer

Asked the other way round (you have been sent a document and want to know whose it really is), the same fields are the answer, and they are a better answer than the usual one.

Every result you will find for this says the same two things: turn on Track Changes, or look at Version History. Both depend on something having been switched on before the editing happened. Track Changes records nothing if it was off, and Version History lives on OneDrive or SharePoint rather than in the file, so a .docx that arrived as an email attachment has none at all. The fields above are in the file itself, always, whether anybody meant them to be or not.

What they will and will not support:

• dc:creator names the account that started it, not the last person to touch it and not necessarily the author. It is whatever was typed into that copy of Word's user name, so it can be a real name, a company, "User", or nothing.
• cp:lastModifiedBy names only the last save. A document that went round six people carries two names, and the four in the middle are not in it.
• Neither is authenticated. Word's user name is a text box in the options. Treat a name as a lead, never as an identification.
• cp:revision and TotalTime are harder to fake casually, because nobody thinks to. A contract described as weeks of work with a TotalTime of eleven minutes, or a revision count of 2, is worth a question, and a revision count in the hundreds on a document said to be a first draft is worth the opposite one.
• Template says where it came from. A document supposedly written from scratch at one firm, built on another firm's .dotx, has a history somebody has not mentioned.
• The rsid values group edits into sessions without naming anybody. They tell you how many separate sittings touched a paragraph, which is sometimes the whole point: one sitting for a passage that was supposedly negotiated.

X-RAY prints all of it from the file, in the browser, without opening the document in Word, which matters, because opening it in Word can update cp:lastModifiedBy and dcterms:modified to you, and then the answer is gone.

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.

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.