PDF Metadata: What Your PDF Says About You
PDF metadata records your name, your software, your operating system and every edit timestamp. Here's what each field holds, why it leaks, and how to read it.

Every PDF carries a block of text fields that nobody looks at before sending the file. That block, the PDF metadata, usually holds the author’s real account name, the exact software and version that made the file, the operating system, and timestamps for creation and every save since. None of it shows on the page, and all of it travels with the file.
You can read it in about ten seconds. Here’s what’s in there and where it comes from.
The short answer
A PDF stores its metadata in two places, and they are separate stores that can hold different values:
- The document information dictionary. A small set of key/value pairs baked into the file’s trailer. Nine fields, defined since the earliest PDF spec. Title, Author, Subject, Keywords, Creator, Producer, CreationDate, ModDate, Trapped.
- The XMP packet. An XML block (Adobe’s Extensible Metadata Platform) embedded as an uncompressed stream. Much larger, much more expressive, and often stuffed with software-specific fields the info dictionary has no room for.
Most viewers show you the info dictionary and stop there. The XMP packet is where the interesting leaks usually sit.
The document information dictionary
This is the classic set. Acrobat’s Document Properties dialog shows most of it, and it is what a script gets when it asks a PDF library for “the metadata”.
| Field | Typical value | What it actually reveals |
|---|---|---|
Title |
“Microsoft Word - Q3 draft v7 FINAL.docx” | The original source filename, revision habits, and often an internal project name |
Author |
“j.okafor” or “Jane Okafor” | A real name or a corporate login ID |
Subject |
Usually empty | Whatever the template author typed once and forgot |
Keywords |
Usually empty | Internal tags, client names, matter numbers |
Creator |
“Microsoft Word for Microsoft 365” | The application the content was authored in |
Producer |
“macOS Version 14.5 Quartz PDFContext” | The library that wrote the PDF, frequently including the OS and its version |
CreationDate |
D:20260114093122+01'00' |
When the file was made, to the second, with the UTC offset (so, the time zone) |
ModDate |
D:20260721171404+01'00' |
The last save. Compare with CreationDate to see how long a document sat in revision |
Trapped |
/False |
Nothing useful. A print production flag |
The date format is worth reading properly. D:20260114093122+01'00' is 14 January 2026 at 09:31:22, one hour ahead of UTC. That offset alone narrows down where the author was sitting, which is the same kind of inference people make from GPS tags in photos. If that comparison is new to you, what is geotagging covers the image side.
The XMP packet, and why the two disagree
XMP arrived later and was meant to replace the info dictionary. It never fully did, so most files carry both. The PDF spec says that where they overlap, XMP should win, but plenty of software ignores this and writes only one side.
That produces the classic mismatch. You change the Author in Acrobat’s Document Properties, the info dictionary updates, and the XMP dc:creator still holds the old name. Some tools then read XMP, some read the dictionary, and two people looking at the same file see two different authors.
XMP also carries fields the dictionary has no equivalent for:
xmpMM:DocumentIDandxmpMM:InstanceID, unique identifiers that persist across saves and let two files be linked as versions of each otherxmpMM:History, an edit trail listing each save action, the software used, and whenpdfaid:part, if the file was made to a PDF/A archival profile- Application-specific namespaces from InDesign, Illustrator, Word, Ghostscript and scanner firmware
The history array is the one that surprises people. It can list five separate save events across three applications, with timestamps, on a file that looks like a clean one-page letter.
What leaks in practice
The two reliable sources of embarrassing PDF metadata are office suite exports and scanners.
Office exports. Word, Excel, Pages, LibreOffice and Google Docs all copy the source document’s author and title into the PDF. Word’s Title defaults to the first heading or to “Microsoft Word - filename.docx”, which is how internal filenames like Redundancy letter template.docx end up in files sent to the person being made redundant. The Author comes from the account that installed the software, which in a company usually means a real name or a login ID that matches an email address.
Scanners and MFPs. Multifunction printers write a Producer string that names the device model and firmware, and sometimes the OCR engine. Some models write the scan operator’s login and the device’s network name. A scanned signed contract can carry the hostname of the machine in the corner of the office.
Design tools. InDesign and Illustrator files carry the fonts used, the color profiles, and often the path of linked assets. A path like /Users/jokafor/Clients/AcmeCorp/2026 pitch/ names the user account, the client, and the project.
The honest framing: none of this is a security hole. It is the file doing exactly what the spec says. It only becomes a problem when the file leaves the building.
How to read PDF metadata
In the browser
Open tools.geotaggingimage.com/pdf/metadata and drop the file in.
- Drag the PDF onto the drop zone, or click Choose files.
- The document information fields appear immediately, with the raw XMP packet below them if the file has one.
- If you want the fields gone, use Remove metadata. That rewrites the file rather than hiding the values.
Nothing is uploaded. The PDF is parsed with pdf-lib inside the page, so the bytes never leave your machine. You can check that yourself: open DevTools, watch the Network tab while you load a file, or disconnect from the internet and confirm the tool still works. No account is needed and the output has no watermark. The free tier caps daily operations and allows 5 files per batch; Pro raises the batch to 50 and removes the cap. The PDF metadata tool page has the details.
In Acrobat or Preview
In Acrobat Reader, go to File > Properties, then the Description tab. That gives you Title, Author, Subject, Keywords, Created, Modified, Application (Creator) and PDF Producer. Click Additional Metadata to see more of the XMP, though Acrobat presents a filtered view rather than the raw packet.
macOS Preview shows a thinner set under Tools > Show Inspector, in the first tab.
With exiftool
For the full picture, including the XMP history array, the command line is still the best option:
exiftool -a -G1 report.pdf
-G1 prints the group each tag came from, so you can see at a glance which values live in PDF (the info dictionary) and which live in XMP-dc, XMP-xmpMM or XMP-pdf. That is how you spot the disagreements. To see only the history:
exiftool -XMP-xmpMM:History -b report.pdf
One caveat about exiftool and PDFs: writing metadata to a PDF is an incremental update, which appends the change rather than replacing the original values. The old ones remain earlier in the file and can be recovered. Use -all:all= with care, and verify the result rather than assuming.
Before you send a PDF
- Check
Titlefirst. It is the field most likely to contain a filename you did not intend to share. - Check
Authoragainst what the recipient should know about your organisation. - Look at
Producerif the file was scanned. Device and firmware strings are common there. - Compare
CreationDateandModDate. A gap tells a story about how long the document was worked on. - If the file went through a designer, look for linked asset paths in the XMP.
- Strip the lot with a real rewrite, not by blanking fields in a viewer that only edits the info dictionary.
The same discipline applies to images attached alongside. A PDF cleaned of metadata sent with a photo full of GPS coordinates is not cleaned. The EXIF viewer shows what a photo carries, and removing EXIF and GPS data covers stripping it.