PDF metadata: what a file quietly remembers

The date printed on a document is a claim. The dates buried in its metadata are a record. Most of the document fraud I see fails on the gap between those two — because the person typing the fake date on the page never thinks about the dates the file is writing about itself at the same moment.

What's actually in there

A PDF typically stores its metadata in two places at once, which turns out to matter enormously.

The first is the Info dictionary — the classic fields: Title, Author, Creator (the application the document was made in, like "Microsoft Word"), Producer (the software that generated the PDF itself), CreationDate and ModDate. The dates include timezone offsets, so a file knows not just when it was made but roughly where in the world the clock that stamped it was set.

The second is XMP — a richer, XML-based block that Adobe introduced later. It duplicates the basics and often adds more: a document ID that persists across edits, an instance ID that changes with each save, sometimes a whole edit history. Some workflows leave surprisingly personal traces here — usernames from the operating system, internal file paths, the name of a template.

Why two copies is a gift to investigators

Here's the beautiful part. Because the same facts live in two places, a clumsy tamperer usually edits one and forgets the other.

Metadata "scrubbing" tools and manual edits tend to reach the Info dictionary — it's the part shown in viewers' document-properties dialogs. XMP sits deeper. When the Info dictionary says one thing and the XMP block says another — different dates, different producer, different title — you're not looking at an oddity. You're looking at a file that has been made to lie about itself, and caught mid-sentence. Consistency checks between the two blocks are among the highest-value tests in document forensics precisely because ordinary software keeps them in sync and tampering breaks the sync.

One inconsistency is a question. A pattern of inconsistencies pointing the same direction is an answer.

The readings that matter most

• ModDate after CreationDate on a document that should have been issued once and never touched — a certificate, a final statement, a signed contract. Editing after issuance is exactly what it sounds like.
• Timezone offsets that don't fit the story. A contract "signed in London" whose timestamps carry a UTC+8 offset has some explaining to do. I've seen the timezone alone unravel a backdating claim: the date was plausible, but the offset placed the file's creation on a different continent from the claimed signing.
• The producer that shouldn't be there. Institutional documents name institutional software. When a bank statement's producer field names a desktop editor — or names nothing, because someone stripped it — the document has a second author.
• Dates that are physically impossible. A creation date of 2012 in a file whose internal features didn't exist until PDF specifications and software of later years. And the sharpest version: content set in a font that hadn't been released on the claimed date — the check that decided Pakistan's Fontgate case.

How to read metadata yourself

You don't need special software to start. Most PDF viewers show the basics under File → Properties. For the full picture, the free command-line tool exiftool dumps everything, including the XMP block a properties dialog won't show you:

exiftool -a -G1 statement.pdf

What the manual route won't do is cross-check — compare Info against XMP field by field, validate date plausibility against the file's structural generation, and correlate the metadata story with the fonts and revision history. That's the part worth automating, and it's built into the free checker on this site as one of its eleven verification checks.

When metadata lies — in both directions

Two honest caveats, because metadata is evidence, not gospel.

Metadata can be faked. Every field is just bytes, and a skilled forger can write anything into them. That's why metadata findings gain their force in combination: faking the Info dictionary, the XMP block, the structural generation markers and the font versions consistently, all at once, is a job almost nobody gets fully right.

And clean metadata proves little on its own. A document generated fresh by a forger has perfectly ordinary, perfectly consistent metadata — it's a genuine record of a fraudulent document's creation. Metadata tells you about the file's history, not the truth of its contents. For that, as always: verify with the issuer.