Authorship traces in PDFs and Office files

Author names, company paths and revision history — the metadata you give away with every contract.

Contracts, offers, invoices, presentations: business documents are full of hidden information. Unlike photos, they rarely contain GPS coordinates — but they are often more revealing about internal processes and people.

Where the data lives

PDF

A PDF stores metadata in two places:

the Info dictionary: Title, Author, Subject, Keywords, Creator, Producer, CreationDate, ModificationDate.
XMP metadata: an XML block that can repeat and extend the same fields, including editing tools and document IDs.

PDFs can also contain embedded files, form data and JavaScript — useful features that are worth checking before you send a file externally.

Fig. 01The two metadata locations of a PDF

Info dictionaryPDF object · key/value

TitleAuthorSubjectKeywordsCreatorProducerCreationDateModDate

XMP metadataXML stream

xmp:CreatorToolxmp:CreateDatexmp:ModifyDatexmpMM:DocumentID

Embedded objectsnot metadata, but informative

JavaScriptEmbedded filesForm fields

A PDF stores the same facts twice, in two different formats. A thorough cleaning tool has to empty both, or the older copy remains.Info dictionary and XMP as defined by PDF 32000-1:2008

Office documents (DOCX, XLSX, PPTX)

Office files are ZIP archives. Inside, you will find:

docProps/core.xml — creator, last modified by, title, subject, keywords, revision number.
docProps/app.xml — application and version, company, manager, template, editing time.
docProps/custom.xml — custom properties added by your organization.

Because these files are ZIP containers, metadata can also hide in file names of internal parts, for example paths with user names.

Fig. 02A DOCX is a ZIP archive

Zcontract.docx

[Content_Types].xmlmanifest
word/document.xmlvisible text
docProps/core.xmlcreator, modified by
docProps/app.xmlcompany, manager, template
docProps/custom.xmlcustom properties

Renaming a .docx to .zip reveals its real structure. The document properties live in three small XML parts, separate from the visible content.Office Open XML packaging, ECMA-376

Fig. 03Inside docProps/core.xml

docProps/core.xml

<?xml version="1.0" encoding="UTF-8"?>
<cp:coreProperties>
  <dc:creator>J. Doe</dc:creator>
  <cp:lastModifiedBy>J. Doe</cp:lastModifiedBy>
  <cp:revision>7</cp:revision>
  <dcterms:modified>2026-08-14T09:21:00Z</dcterms:modified>
</cp:coreProperties>

This is the actual payload. Two lines name the author, and the revision counter tells the recipient how many negotiation rounds the document went through.Dublin Core and OPC core properties, ECMA-376 Part 2

What gets exposed in practice

Who wrote it. dc:creator and cp:lastModifiedBy name individuals.
Where they work. Company and Manager fields identify the organization and reporting lines.
How often it changed. The revision counter and total editing time show how many negotiation rounds it went through.
Which tools were used. Application and version fields show your software stack — relevant for attackers looking for known vulnerabilities.
Which template it came from. Template names sometimes include internal project codes.

Cleaning documents correctly

ShredHub rewrites the document properties instead of deleting the parts, so the file stays valid in Word, Excel and PowerPoint:

core.xml keeps only normalized timestamps.
app.xml keeps the application name but drops company, manager and template.
Custom properties are emptied.
Macros are not removed — ShredHub warns you instead, because removing them changes the file type and can break workflows. Remove macros in your editor if they are not needed.

For PDFs, ShredHub clears the Info dictionary, removes the XMP stream and JavaScript triggers, then verifies the result.

A habit worth building

Add a cleaning step to your document workflow — right before "send to external recipient". It takes seconds, works without special software, and prevents the small data exposures that add up over time.