Skip to main content
All articles
How-To
7 min read

How to Remove Tracked Changes Before Sending a Word Document

Accepting tracked changes in Word removes the visual markup, but the revision history can persist in the file's XML structure. Here's how to fully clean a Word document before sharing.

The problem with "Accept All Changes"

You've finished editing a Word document. You click Review > Accept All Changes. The red and blue markup disappears. The document looks clean. You email it.

But the revision history may still be in the file.

A Word document (.docx) is not a single file. It is a ZIP archive containing dozens of XML files. When you track changes in Word, the insertions, deletions, and formatting changes are stored as XML nodes in the document's main content file (word/document.xml). Comments are stored in a separate XML file (word/comments.xml). Author information is stored in word/core.xml and word/app.xml.

When you click "Accept All Changes," Word updates the visual rendering — the markup disappears. But depending on how the document was saved, revision data may persist in the XML structure. Comments that were "resolved" in the interface may still exist in the comments XML. The author field, company name, total editing time, and revision count remain in the document properties.

This means the person receiving your document can potentially:

  • See what text you deleted during editing
  • Read comments you thought were removed
  • See who authored or last modified the document
  • See the company name associated with the document
  • See how long you spent editing and how many revisions you made

The manual approach (Word's built-in tools)

Word includes a tool called Document Inspector that can find and remove some of these hidden data points. Here is the step-by-step process.

Step 1: Accept all tracked changes

  1. Open your document in Word
  2. Go to the Review tab
  3. Click the dropdown arrow next to "Accept" in the Changes group
  4. Select "Accept All Changes and Stop Tracking"

This removes the tracked change markup and stops future tracking.

Step 2: Delete all comments

  1. Stay on the Review tab
  2. Click the dropdown arrow next to "Delete" in the Comments group
  3. Select "Delete All Comments in Document"

This removes comment threads from the visual interface.

Step 3: Run Document Inspector

  1. Go to File > Info
  2. Click "Check for Issues"
  3. Select "Inspect Document"
  4. In the Document Inspector dialog, check all categories:
    • Comments, Revisions, Versions, and Annotations
    • Document Properties and Personal Information
    • Custom XML Data
    • Headers, Footers, and Watermarks (if needed)
    • Invisible Content
    • Hidden Text
  5. Click "Inspect"
  6. For each category that shows results, click "Remove All"

Step 4: Check document properties manually

  1. Go to File > Info
  2. On the right side, check the Properties panel
  3. Verify that Author, Last Modified By, Company, and other fields are cleared or acceptable

Step 5: Save as a new file

  1. Go to File > Save As
  2. Save with a new filename
  3. This creates a new file without the revision history of the original

Where the manual approach falls short

The Document Inspector is a useful tool, but it has limitations that matter in professional contexts.

It does not always catch everything

Document Inspector operates at the Word application level — it removes what Word knows about. But the .docx format stores data in XML, and some data persists in XML nodes that Word's inspector does not examine. For example:

  • Template path in settings.xml: The word/settings.xml file may contain a path like C:\Users\jsmith\AppData\Roaming\Microsoft\Templates\CompetitorCorp.dotx. This reveals the file path on the author's computer, including their username and the template they used. Document Inspector does not always clear this field.

  • Resolved comments: In some Word versions, resolved (but not deleted) comments remain in the word/comments.xml file even after Document Inspector runs. The comments are not visible in Word's interface, but they exist in the XML and can be extracted by parsing the file.

  • Custom document properties: Some organizations use custom properties for workflow tracking (document status, approval chain, classification level). These are stored in docProps/custom.xml and may not be caught by Document Inspector's default categories.

  • Embedded objects with their own metadata: If the document contains embedded Excel charts, images, or OLE objects, each of those embedded items carries its own metadata (author, creation date, software version). Document Inspector does not recursively inspect embedded objects.

It does not verify removal

After Document Inspector runs, you are trusting that it worked. There is no verification step — no re-scan, no confirmation that the data is actually gone from the XML. You are relying on Word's implementation being complete and correct.

It requires manual execution every time

Document Inspector is not automated. Every document requires the same manual process: open, inspect, remove, save. In a workflow where you send dozens of documents per week, manual inspection is the step that gets skipped when deadlines press.

What complete OOXML hygiene looks like

A thorough cleaning of a Word document requires operating at the XML level — inside the ZIP archive, on the individual XML files that compose the document.

Here is what a complete sanitization covers:

Document properties (docProps/core.xml)

  • Author: The name of the person who created the document. Set by the Windows account or Office profile.
  • Last modified by: The name of the last person to save the document.
  • Revision count: How many times the document was saved.
  • Total editing time: The cumulative time the document was open for editing (in minutes).
  • Creation date and modification date: Timestamps.
  • Title, subject, keywords, description: Optional fields that may contain sensitive information.

Application properties (docProps/app.xml)

  • Application name and version: e.g., "Microsoft Office Word" and "16.0".
  • Company name: Set from the Office installation or organizational template. This field frequently exposes the organization that created the document — even when the document is being sent to a different organization.
  • Template used: The name of the template the document was based on.

Document content (word/document.xml)

  • Tracked insertions and deletions: XML nodes (<w:ins> and <w:del>) that record every tracked change, including the original text, the change author, and the change timestamp.
  • Formatting changes: Tracked formatting revisions stored as <w:rPrChange> nodes.
  • Bookmarks referencing deleted text: Bookmarks that point to ranges of text that have been deleted.
  • Move-from and move-to markers: Records of text that was moved from one location to another.

Comments (word/comments.xml)

  • Comment threads: Each comment includes the author name, timestamp, and comment text.
  • Resolved comments: Comments marked as resolved in the interface but still present in the XML.
  • Replies to comments: Nested comment replies, each with their own author and timestamp.

Settings (word/settings.xml)

  • Default template path: Often contains the full file path including the user's home directory name.
  • Compatibility settings: May reveal the Word version used.
  • Document protection settings: May indicate previous editing restrictions.

Custom XML (customXml/)

  • Custom data parts: Some organizations inject workflow metadata, classification labels, or DRM information into custom XML parts.

A practical approach

For most professionals, the goal is simple: send a document that contains only the visible content and nothing else. No author name. No revision history. No company name. No editing time. No comments. No template paths.

The manual Word approach (steps 1-5 above) handles the most common cases. If you follow those steps consistently, you will catch the majority of metadata exposures.

For complete assurance — particularly in legal, healthcare, compliance, or financial contexts where metadata exposure has professional consequences — a dedicated tool that operates at the XML level and verifies removal by re-parsing the output provides a higher level of confidence.

The key difference is the verification step. When you run Document Inspector, you trust that it worked. When a tool re-scans the output and confirms that tracked changes, comments, and author data are no longer present in the XML, you have evidence that it worked.

Purgit scans Word documents at the XML level — tracked changes, comments, author fields, company names, template paths, and revision history. It removes findings from the document structure and verifies removal by re-parsing the output. One scan, one report, complete confidence.

[Scan a File Free]

Scan before you share.

Try Purgit free — no account required.

Scan a File Free