How to remove reviewer names and internal properties before public disclosure
- Step 1Apply all visible-text redactions in the source first — This is the most important step. The wiper removes metadata, NOT visible body text. Names, addresses, and exempt passages must be redacted (deleted, not just highlighted black) in Word/Excel/PowerPoint before you export — black highlighting over text does not remove the underlying characters. The wiper cleans the container's metadata after the body redaction is done.
- Step 2Accept or reject all track changes — Track-changes redlines live inside
word/document.xml(the body) and are NOT removed by this tool — and a redline can re-expose deleted text plus its author. Open the document and Review → Accept All Changes so no revision history reaches the public file. Verify Track Changes is turned off afterwards. - Step 3Drop the document onto the wiper — The picker accepts
.docx,.xlsx, and.pptxonly. Drag the release candidate in. On the public browser path JSZip reads it locally — the pre-release document is never transmitted. Legacy.doc/.xls/.pptare binary OLE files and are rejected; Save As the modern format first. - Step 4Let it strip and repack — There are no options — the schema is empty by design. The tool removes the fixed list of
docProps/*, every comment / people / persons / commentAuthors stream, and the embedded thumbnail, runs a wildcard sweep for numbered comment files, and repacks withgenerateAsync. - Step 5Record the removedEntries count for the release file — The result reports
removedEntries— the number of metadata files deleted from this specific document. Record it in your release log alongside the document reference, so the disclosure file carries an auditable note that metadata was scrubbed. A run also emits an audit log entry (no file content stored). - Step 6Verify, then publish the -clean copy — Re-open the cleaned file and check File → Info → Properties — Author, Company, custom properties, and the comments pane should all be empty. For certainty, copy it to a
.zipand confirmdocProps/core.xmland the comment streams are absent. Publish that-cleancopy; do not open-and-save it again, or Office re-writes a freshcore.xml.
Disclosure-risk streams removed before release
The streams this tool deletes and the disclosure risk each one carries in a public release. A wildcard sweep also catches numbered comment streams.
| Stream removed | Disclosure risk if left in | Applies to |
|---|---|---|
word/comments.xml + people.xml + threadedComments.xml | Names and candid internal remarks of reviewers — content usually withheld; has leaked 'redacted' names | .docx |
xl/comments1.xml + xl/persons/person.xml | Cell-comment author names and internal notes on the data | .xlsx |
ppt/commentAuthors.xml + ppt/comments/comment1.xml | Slide review comments and the author registry | .pptx |
docProps/core.xml | Creator and Last Modified By — names the drafting and approving staff | All three |
docProps/app.xml | Agency, internal template name, Total Editing Time | All three |
docProps/custom.xml | Records-management classification, case / matter number, routing code | All three |
docProps/thumbnail.jpeg / thumbnail.png | A rendered first-page preview that can pre-date a visual redaction | All three |
What the wiper does NOT do — read before relying on it
Critical limits for a records team. The wiper is a metadata step, not a redaction tool; visible-text redaction must happen in the source application.
| Not handled | Why | Required step |
|---|---|---|
| Redacting visible text (names, addresses, exempt passages) | Body text lives in word/document.xml; the wiper removes metadata files only | Delete the text in the source app first — black highlighting is not redaction |
| Track changes / revision marks | Redlines are body nodes, not a property stream | Review → Accept All Changes, then verify Track Changes is off |
| Hidden rows/columns, hidden slides, hidden sheets | Out of scope — body content, not metadata | Unhide and delete in the source app |
| Text inside embedded images (scanned exhibits) | Per-image content inside media/, not a document property | Redact the image itself before inserting |
| PDF releases | PDFs are not OOXML ZIPs and are rejected | Use pdf-pii-text-redactor for PDF PII, then pdf-history-sanitizer for PDF metadata |
Plan, limits, audit, and output
The tool requires the Pro plan; it emits an audit log entry suited to records workflows.
| Property | Value | Notes |
|---|---|---|
| Minimum plan | Pro | A Free run returns Office Doc Property Wiper requires the pro plan. |
| File-size limit | Pro 100 MB · Pro-media 500 MB · Developer 2 GB | Oversize files error before processing |
| Accepted input | .docx, .xlsx, .pptx | Legacy binary formats rejected |
| Output | Repacked file, original name + -clean, plus removedEntries | API path returns outputBase64, mime application/octet-stream |
| Audit log | Emitted (no file content stored) | A run is recorded for dashboard/enterprise audit |
| Privacy | Browser-side; no upload | Pre-release documents stay on the agency machine / network |
Cookbook
Before/after structure from real release candidates. Staff names and case numbers are anonymised; the entry paths are exactly what the tool acts on.
A memo released with reviewer comments still inside
An internal memo cleared for release. The visible text is already redacted, but the container names the drafting officer in core.xml, the case number in custom.xml, and three reviewers in the comment streams. The wipe removes all of it; the body redaction was done in Word first.
Before (unzip Release-Memo.docx): docProps/core.xml <- Creator: Officer A; Last Modified By: Dir. B docProps/app.xml <- Company: Dept of X; Template: InternalMemo.dotx docProps/custom.xml <- CaseNumber=FOI-2026-0418; Routing=LEGAL word/comments.xml <- 3 reviewer comments word/people.xml <- 3 reviewer names word/document.xml <- text already redacted; may have track changes! After wipe (Release-Memo-clean.docx): docProps/core.xml REMOVED docProps/app.xml REMOVED docProps/custom.xml REMOVED <- case number + routing gone word/comments.xml REMOVED word/people.xml REMOVED word/document.xml UNCHANGED <- accept track changes first! removedEntries: 5
A released spreadsheet with internal cell comments
A data release where analysts left cell comments flagging caveats. The comment authors and notes must not be disclosed. The wipe removes the comment and persons streams and the properties.
Before (unzip Data-Release.xlsx): docProps/core.xml <- Creator + Last Modified By docProps/custom.xml <- Classification=OFFICIAL-SENSITIVE xl/comments1.xml <- 9 analyst caveats xl/persons/person.xml <- analyst identity map After wipe (Data-Release-clean.xlsx): docProps/core.xml REMOVED docProps/custom.xml REMOVED <- classification stripped xl/comments1.xml REMOVED xl/persons/person.xml REMOVED removedEntries: 4
A briefing deck with the embedded preview thumbnail
A PowerPoint briefing cleared for release with slide comments from the review and the embedded first-slide thumbnail that pre-dates the redaction pass. All are removed.
Before (unzip Briefing.pptx): docProps/core.xml docProps/thumbnail.jpeg <- preview of slide 1 (pre-redaction) ppt/comments/comment1.xml <- 4 review comments ppt/commentAuthors.xml <- reviewer registry After wipe (Briefing-clean.pptx): docProps/core.xml REMOVED docProps/thumbnail.jpeg REMOVED <- stale preview gone ppt/comments/comment1.xml REMOVED ppt/commentAuthors.xml REMOVED removedEntries: 4
Verifying the release file for the disclosure log
A records team needs an auditable check. Rename the cleaned copy to .zip, confirm the property and comment streams are gone, and record the removedEntries count in the release log.
$ cp Release-Memo-clean.docx verify.zip $ unzip -l verify.zip | grep -E 'docProps|comments|people' (no core/app/custom.xml, no comments.xml, no people.xml) # Result panel reported: removedEntries: 5 inputBytes: 167400 outputBytes: 142060 # Release log: 'metadata scrubbed; 5 streams removed; verified by re-unzip'
Controlled batch scrubbing via the local runner
Because this tool is server-safe, a public body can run it through an @jadapps/runner on its own network so pre-release documents never reach JAD's servers. The schema has no options.
# 1. Read the schema (empty options array):
GET /api/v1/tools/office-doc-property-wiper
-> { options: [], minTier: "pro", outputType: "blob" }
# 2. POST each release candidate to the local runner:
POST http://127.0.0.1:9789/v1/tools/office-doc-property-wiper/run
(multipart: Release-Memo.docx)
# 3. Runner returns the cleaned file as base64:
{
"outputBase64": "UEsDBBQA...",
"inputBytes": 167400,
"outputBytes": 142060,
"removedEntries": 5,
"mime": "application/octet-stream"
}Edge cases and what actually happens
Redacted text is still readable in the released file
Out of scope — redact in source firstThe wiper removes metadata, not visible body text. If names or exempt passages were only highlighted black rather than deleted, the underlying characters remain in word/document.xml and are fully recoverable. Visible-text redaction must be done in the source application (delete the text) before you run the wiper. The wiper closes the metadata gap, not the body-text gap.
Track changes re-expose deleted text
By designTrack-changes nodes live inside the document body and are deliberately not removed. A redline can carry both the deleted text and the author who deleted it. Accept all changes in Word's Review tab and confirm Track Changes is off before exporting, or the revision history reaches the public file.
Reviewer names leaked despite the visible redaction
Fixed by this toolThis is the classic public-records failure: the body is redacted but word/comments.xml / people.xml (or the Excel/PowerPoint equivalents) still name the reviewers. The wiper deletes those streams plus a wildcard sweep for numbered comment files, so reviewer identity in the comment metadata is removed — provided you also handled track changes and visible text.
Legacy .doc / .xls / .ppt release candidate dropped
RejectedLegacy formats are binary OLE compound files, not OOXML ZIPs, and the accept filter excludes them. Open in the source app and Save As the modern format first, then redact and wipe the converted copy.
File exceeds the plan size limit
Error: exceeds limitA file over your tier's cap fails before processing with a message like File "X.xlsx" is 142 MB — exceeds the 100 MB limit for your plan. Pro is 100 MB, Pro-media 500 MB, Developer 2 GB. A large release file usually has embedded media; split or compress in the source app if needed.
Running on the Free plan
Rejected: requires ProThe tool's minimum plan is Pro. A Free-tier run is rejected with Office Doc Property Wiper requires the pro plan. before any file is read.
removedEntries comes back as 0
ExpectedZero means the document had none of the targeted property or comment streams — possible for a freshly produced file. It is not an error; the file is still repacked and saved with the -clean suffix. Still apply the visible-text redaction and track-changes steps separately.
Classification property removed
Removed — confirm policyA records-management classification stamped into docProps/custom.xml (e.g. OFFICIAL-SENSITIVE) is removed with the rest of that stream. Usually correct for a public release, but confirm with your information-governance policy whether the classification metadata should be stripped or retained on the disclosure copy.
Author reappears after editing the cleaned file
ExpectedOffice writes a fresh, minimal docProps/core.xml naming the current user as Creator the next time you open and save the cleaned file. The wipe was correct when it ran. Make the wipe the last step before publication and do not open-and-save the cleaned copy afterwards.
Scanned exhibit still contains readable PII
Out of scopeText inside an embedded image (a scanned exhibit) is image content inside word/media/, not a document property stream, and survives the wipe. Redact the image itself before inserting it; the wiper does not process per-image content.
Frequently asked questions
Does this redact the names in the document text?
No. The wiper removes metadata streams, not visible body text. Names, addresses, and exempt passages in the document body must be deleted in the source application (Word/Excel/PowerPoint) before you run the wiper — and they must be deleted, not just highlighted black, because black highlighting leaves the underlying characters recoverable. The wiper closes the metadata half of a release; visible-text redaction is a separate, prior step.
Will it remove reviewer names and internal comments?
Yes — this is its core value for disclosure. It deletes Word comments.xml / commentsExtended.xml / people.xml / threadedComments.xml, Excel xl/comments1.xml / threaded comments / xl/persons/person.xml, and PowerPoint ppt/comments/comment1.xml / ppt/commentAuthors.xml, plus a wildcard sweep for numbered comment files. Reviewer names and candid internal remarks in the comment metadata are removed.
Does it remove track changes?
No. Revision marks live inside word/document.xml (the body), not a metadata stream, and the wiper deliberately does not touch the body. A redline can re-expose deleted text and its author. Accept all changes in Word's Review tab and confirm Track Changes is off before exporting.
Will the classification or case number be stripped?
Yes, if they are stored as custom document properties — docProps/custom.xml is deleted entirely, and records-management systems commonly stamp a classification label, case number, or routing code there. Confirm with your information-governance policy whether the classification metadata should be removed from or retained on the disclosure copy.
Is the pre-release document uploaded anywhere?
On the public website, no. JSZip unpacks, strips, and repacks the file in your browser, so a document still under review never leaves the agency machine. The optional API path runs through an @jadapps/runner on your own network, keeping batch processing local too. A counter of runs (no content) is recorded for audit.
Is there an audit trail for the release log?
Yes. The run emits an audit log entry (no file content stored) and the result panel reports a removedEntries count you can record in your disclosure log. For independent verification, copy the cleaned file to a .zip and confirm the property and comment streams are absent.
Does it strip the embedded thumbnail?
Yes — docProps/thumbnail.jpeg and docProps/thumbnail.png are deleted. The thumbnail is a rendered preview of the first page that can pre-date a visual redaction pass and survive into a published thumbnail, so removing it closes that leak.
What about a PDF release?
PDFs are not OOXML ZIPs and are rejected by this tool. For a PDF release, redact the PII text with pdf-pii-text-redactor, then scrub the PDF's Info dictionary and XMP with pdf-history-sanitizer. This tool handles OOXML Office files only.
What plan and file size do I need?
The Pro plan or higher. File-size caps follow the Security family limits: Pro 100 MB, Pro-media 500 MB, Developer 2 GB per file. An oversize file errors before processing with a message naming the file and your plan's limit. A Free-tier run is rejected before the file is read.
Why does the author come back if we edit the cleaned file?
Office writes a fresh, minimal docProps/core.xml naming the current user as Creator the next time the document is opened and saved. The wipe was correct when it ran. Make the wipe the last step before publication and do not open-and-save the cleaned copy afterwards.
How do we confirm the file is clean before publishing?
Check File → Info → Properties in the source app — Author, Company, custom properties, and the comments pane should be empty. For an auditable check, copy the cleaned file to a .zip and list it: docProps/core.xml, app.xml, custom.xml, and the comment streams should be absent. Record the removedEntries count in your release log.
What about hidden sheets or scanned exhibits?
Hidden rows, columns, slides, and sheets are body content, not metadata, and survive the wipe — unhide and clear them in the source app. Text inside a scanned exhibit is image content inside word/media/ and is not processed; redact the image before inserting it. The wiper removes document-level metadata streams only.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.