Doc Sanitizer support

Help and frequently asked questions · Last updated 22 May 2026

What is Doc Sanitizer?

Doc Sanitizer is a local-first macOS app that strips hidden data from Word (.docx), Excel (.xlsx) and PowerPoint (.pptx) documents — authors and editors, tracked changes, comments, speaker notes, pivot caches, hidden sheets and slides, custom XML compliance tags, embedded files, VBA macros. Every save is re-inspected and verified before the app reports success.

It is a companion to Image Sanitizer (hidden data in JPEG/PNG/HEIC/WebP/TIFF), PDF Sanitizer (hidden data in PDFs), and PDF Redaction (visible content in PDFs). Use Doc Sanitizer when you need to share an Office document without revealing who wrote it, who edited it, what they changed, what they wrote in the comments, or what data sat behind a pivot table before you filtered it.

Is Doc Sanitizer stable? What does the beta status mean?

Doc Sanitizer is currently in beta. The core sanitisation engine is feature-complete and every save is verified before completing, but the app has not yet had wide real-world exercise across every kind of document in the wild. Treat beta builds accordingly:

• Always keep the original document. Doc Sanitizer never overwrites it by default, but you should keep your own backups regardless.
• If the sanitised output is going somewhere sensitive (publication, court filing, news outlet, FOIA response), open it in a different OOXML viewer and re-check the metadata using a separate tool such as unzip + cat docProps/core.xml or one of the open-source OOXML inspectors.
• Report anything unexpected — that’s what beta is for.

How does sanitisation work?

OOXML documents (.docx / .xlsx / .pptx) are zip archives of XML and binary parts. Doc Sanitizer ships a per-format walker that knows which parts carry hidden data and which are visible content. None of them re-encodes the visible body — each one rewrites the zip dropping the metadata-bearing parts and surgically rewriting the parts that point at them.

• Word (.docx). Walks word/document.xml to strip tracked-change wrappers (w:ins, w:del, w:moveFrom, w:moveTo) while accepting insertions and dropping deletions. Removes comment anchors. Drops word/comments.xml and the modern threaded-comment companions (commentsExtended, commentsIds, commentsExtensible, people.xml) wholesale. Strips revision-save IDs (w:rsids) from word/settings.xml. Drops everything under word/embeddings/, word/vbaProject.bin, and customXml/. Replaces docProps/core.xml and docProps/app.xml with empty shells and removes docProps/custom.xml.
• Excel (.xlsx). Drops xl/comments*.xml, the threaded-comments tree, and the persons registry that often leaks email-shaped userIds. Drops the entire xl/pivotCache/ directory (the original unfiltered source rows behind every pivot table), xl/externalLinks/, xl/connections.xml (data source connection strings), xl/queryTables/, embeddings and VBA. Rewrites xl/workbook.xml to drop now-dangling <pivotCaches>, <externalReferences> and <connections> blocks. Hidden sheets are surfaced in the inspection panel but preserved — deleting visible-but-hidden content is your call.
• PowerPoint (.pptx). Drops ppt/notesSlides/ wholesale — the speaker-notes pane is the headline pptx leak. Removes ppt/comments/, the classic ppt/commentAuthors.xml registry, embeddings, ppt/ink/, ppt/tags/, VBA, and customXml/. Hidden slides are title-sniffed and surfaced but preserved.

Across all three formats, the writer also rewrites [Content_Types].xml to drop the <Override> entries for stripped parts, and every .rels file to remove relationships pointing at parts that no longer exist. External relationships (hyperlinks to URLs) are deliberately preserved — they’re visible content.

After writing, Doc Sanitizer re-opens the output zip and re-runs the inspection. If any metadata category remains, the tainted file is deleted and you see a clear failure — you don’t accidentally ship a file you think is clean.

What kinds of hidden data does it actually find?

The reveal is the product. Doc Sanitizer doesn’t say “Document properties: 814 B” — it decodes the actual values and shows them to you before you sanitise. A typical Office-saved file will surface something like:

• Author: the name the file was originally created under (often someone else, if you inherited the template).
• Last modified by: every person who has saved the file since.
• Created / Modified: timestamps to the second.
• Company: whatever your Office installation is configured with, often a corporate identity.
• Manager: a name from the same Office configuration.
• Template path: file-system path to the template the document was built from — sometimes a UNC path that reveals an internal server.
• Tracked changes (Word): every insertion and deletion that was ever made, with the author’s name, date, and the text of the change. Yes, even after you clicked “accept all changes” in Word.
• Comments: the full body of every comment, with the author’s name and date. Threaded comments add email-shaped userId attributes that often contain a real email address.
• Pivot caches (Excel): the source range (e.g. HiddenCache!A1:D1000) and column names (e.g. EmployeeName, Salary, Department) of every pivot in the workbook. The cache itself contains the original unfiltered rows.
• Hidden sheets (Excel): their names and a flag of how aggressively they were hidden.
• External workbook references: file-system paths to other Excel files this one links to. Often a file:// URL revealing the original author’s directory structure, or a SharePoint URL.
• Connection strings: ODBC / OLE DB / OData strings, sometimes with embedded credentials.
• Speaker notes (PowerPoint): the full text of every note in the speaker-notes pane, labelled by the slide it attaches to.
• Hidden slides (PowerPoint): titles of slides marked show="0".
• SharePoint compliance tags: if the file ever lived in SharePoint, customXml/ usually carries content-type GUIDs, retention policies, and document-management identifiers.
• VBA macros: the binary macro project, which routinely embeds the developer’s machine username and paths from the VBA editor.
• Embedded files: OLE objects (other Office files, PDFs, images) stored inside the document.

Can I right-click a document in Finder to sanitise it?

Yes — open Doc Sanitizer’s Settings, find Finder integration, and turn on “Show Sanitize with Doc Sanitizer in Finder right-click menu”. This installs a small macOS Quick Action workflow into ~/Library/Services/. From then on, right-clicking any Word, Excel or PowerPoint document in Finder offers Quick Actions → Sanitize with Doc Sanitizer, which launches the app (or hands the file to it if it’s already running) and pre-loads the document.

Nothing is installed without your consent, and turning the toggle off again uninstalls the workflow cleanly.

How is this different from PDF Sanitizer / Image Sanitizer?

Doc Sanitizer is the Office-document counterpart to the PDF and image tools. The four apps form a workflow for sharing files without leaking hidden data:

• PDF Redaction removes visible content from a PDF (text and image regions you draw rectangles over).
• PDF Sanitizer removes hidden data from a PDF (metadata, scripts, attachments, comments).
• Image Sanitizer removes hidden metadata from a JPEG, PNG, WebP, TIFF, or HEIC image (EXIF, GPS, XMP, IPTC).
• Doc Sanitizer removes hidden data from a Word, Excel or PowerPoint document.

All four are local-only, never overwrite the original, and verify the output before reporting success.

Where is my data stored?

The documents you open stay where you opened them from — Doc Sanitizer does not copy your input files anywhere and never overwrites the original. The decoded metadata is held in memory while the file is open and discarded when you open a different document or quit the app. Sanitised output is written only where you tell the dialog to put it.

Doc Sanitizer makes no network connections by default. An optional auto-update check can be enabled in Settings → Updates; if turned on, it makes one HTTPS request per launch to GitHub to look for a new version, and sends no document content, no telemetry, no user data. See the privacy policy for the full detail.

System requirements

• macOS 11 (Big Sur) or later.
• Apple Silicon (M1 or later) or Intel. Doc Sanitizer ships separate disk images for each — pick the one matching your Mac.
• Around 100 MB of free disk space.

How do I download the beta?

Doc Sanitizer is in public beta. Download the disk image matching your Mac’s processor:

• DocSanitizer-aarch64.dmg — Apple Silicon (M1, M2, M3, M4).
• DocSanitizer-x86_64.dmg — Intel Macs.

Not sure which one? Click the Apple menu → About This Mac. If the “Chip” or “Processor” line starts with “Apple”, choose Apple Silicon. If it mentions Intel, choose Intel.

Both disk images are signed with our Developer ID Application certificate and notarized by Apple.

How do I install it?

1. Double-click the DocSanitizer-aarch64.dmg (or DocSanitizer-x86_64.dmg) file to open it.
2. Drag the Doc Sanitizer app into your Applications folder.
3. Eject the disk image (drag it to the Trash, or use the eject button in Finder).
4. Open the app from Applications. On first launch macOS may take a few seconds to verify the notarization; this is normal.

If you launch Doc Sanitizer from anywhere other than Applications (for example, by double-clicking the app inside the mounted DMG), the app will show a clear warning on launch and offer to quit so you can install it properly. Auto-updates require the app to live in Applications.

What happens on first launch?

The first time you open Doc Sanitizer after downloading it, macOS will show a confirmation dialog that looks like:

“Doc Sanitizer” is an app downloaded from the internet. Are you sure you want to open it?

[Your browser] downloaded this file today at [time]. Apple checked it for malicious software and none was detected.

[Cancel] [Open]

This dialog is normal and expected — every app downloaded through a web browser triggers it on first launch, regardless of how cleanly it is signed. The reassuring line is “Apple checked it for malicious software and none was detected”: this is macOS confirming that the app’s notarization and signature both check out. Click Open and Doc Sanitizer will launch.

You will then see a one-time first-run modal in Doc Sanitizer itself, explaining the local-only promise and asking whether you want to opt in to automatic update checks. The default is “no”, and you can change your mind later in Settings → Updates.

macOS says the app is from an unidentified developer

This is a different and rare warning. The wording you are looking for is one of:

• “… cannot be opened because it is from an unidentified developer”
• “… cannot be opened because Apple cannot check it for malicious software”
• “… will damage your computer”

None of these should happen with the disk image you download from our official link — the app and the disk image are both signed with our Developer ID Application certificate and notarized by Apple. If you do see one of them, please stop and email us at support@whiteforgetech.co.uk before bypassing the warning. It probably means you have an unofficial copy of the app, or that something happened to the download in transit.

The friendly “downloaded from the internet, are you sure?” dialog described in the previous section is not one of these warnings.

Which document formats are supported?

Doc Sanitizer supports the three OOXML formats Microsoft Office produces:

• Word — .docx.
• Excel — .xlsx.
• PowerPoint — .pptx.

The older binary formats (.doc, .xls, .ppt) and OpenDocument formats (.odt, .ods, .odp) are not currently supported. If a format you need isn’t on this list, let us know — the feature request channel is open.

Verification failed when I saved — what does that mean?

Doc Sanitizer re-opens every sanitised output and re-runs the format-specific inspection. If any metadata category we promised to remove still appears in the post-sanitisation report, verification fails: the tainted output is deleted and you see an error with the leak counts.

This is the system working as designed — it means Doc Sanitizer caught a case where it could not be sure the file was clean. Email us a description of the document (or, if you can, a small synthetic file with the same structural shape that reproduces the failure) at support@whiteforgetech.co.uk and we will look into it.

How do I report a bug?

Two channels, whichever you prefer:

• Public Issue tracker at github.com/whiten1968/DocSanitizer-downloads/issues. Faster for us to triage, and other users can see what’s being worked on. Don’t attach actual documents here — it’s a public repository.
• Email support@whiteforgetech.co.uk for anything you’d rather keep private (e.g. you need to attach a sensitive document to reproduce the issue).

Either way, please include:

• What you were doing when the problem happened;
• What you expected and what actually happened;
• Your macOS version (Apple menu → About This Mac);
• The Doc Sanitizer version (Settings → bottom of the panel).

If the bug only reproduces with a specific document, try to construct a small synthetic file with the same structural shape and share that. Send original documents only if we ask, and only via email.

How do I request a feature?

Open a Discussion on the downloads repo (Ideas category), or email support@whiteforgetech.co.uk. We read every request.

Contact

Whiteforge Technologies Ltd
support@whiteforgetech.co.uk

Back to Doc Sanitizer overview →