DOCX Metadata Inspector (Core Properties, Author, Dates)
Every .docx file carries metadata that Word maintains automatically: the author name, the last person to save the file, the creation and last-modified timestamps, a revision counter that increments on every save, a cumulative editing-time tally, and the document title and subject if they were ever set. That metadata is invisible while the document is open in Word but persists in the file and travels with every copy. This tool reads it in your browser — useful before publishing a document to a public audience (the metadata is a common channel for accidental author-name leaks) and useful for compliance review (document-provenance and editing-time tracking are sometimes part of evidence-handling procedures).
Which Fields the Tool Extracts
The .docx core properties (the core.xml part inside the zip, conforming to the Dublin Core schema): creator (the original author), lastModifiedBy (the last user to save), title, subject, description, keywords, category, language, version, created date, modified date, lastPrinted date, revision number, and the cumulative document statistics from the app.xml part: total editing time (in minutes), word count, character count, line count, paragraph count, and page count. Some of these are populated automatically by Word; others are only set when the user explicitly fills them in via File > Info > Properties. The tool shows every field that has a value and notes which ones are blank.
Why Metadata Audits Matter
The single most common metadata-related embarrassment is the author-name leak: a document drafted internally and sent to a counterparty still has the drafter's name in the creator field, which can reveal information the sender did not intend to share (the internal team structure, whether the document was drafted by junior or senior staff, whether multiple internal contributors edited it). Less commonly, the cumulative editing time can reveal that a "day-of" document was actually drafted over weeks, or vice versa. For legal documents, the metadata is sometimes discoverable evidence; for press releases and policy documents, it is usually best stripped before publication.
How Metadata Stripping Works (And Where This Tool Fits)
Stripping metadata from a .docx is done in Word via File > Info > Inspect Document > Document Inspector, which removes most fields and replaces some (like creator) with a generic value. The result is not always complete — some fields can be re-populated on the next save — and the inspection step itself does not always show what was present before. This tool fits in the pre-stripping audit step: see what's there before you decide what to strip, and re-run after stripping to confirm the strip succeeded. It does not modify the file — it is a read-only inspector — so a stripping operation needs a separate tool or Word itself.
Privacy and the Browser-Only Posture
Everything happens locally. The .docx is parsed as a zip in your browser, the core.xml and app.xml parts are extracted and the metadata fields read out, and the result is displayed in the page. Nothing crosses the network — critical for the legitimate use cases of this tool, which all involve documents the user does not want to disclose externally. mammoth.js's underlying zip reader is well-tested (it's the same engine that powers the DOCX-to-Markdown conversion in the sister tool); the inspector adds a thin metadata-extraction layer on top of it. The Network tab confirms no upload while the tool runs.
Pair this with related UDT document tools: DOCX to Markdown for converting a stripped document to a publication-ready format, PDF Metadata Inspector for the equivalent inspection on PDFs, PDF Editor for the broader PDF workflow, and EXIF Viewer for the same kind of metadata audit on images.
Frequently Asked Questions
Built by Derek Giordano · Part of Ultimate Design Tools