What PDF metadata can and cannot prove
Every guide to spotting a forged document reaches the same place within two paragraphs: check the metadata. It is good advice, and it is the most over-read evidence in the whole field. Metadata is fast, free and often decisive against careless forgery — and it is routinely used to support conclusions it cannot carry, in both directions.
Being precise about where the evidence stops is not a caveat. It is the difference between a check you can defend and a guess you happen to be confident about.
What is actually in there
A PDF is a container, and it records things about its own construction that nobody types in deliberately:
- Producer and Creator — the software that wrote the file, and the application the content came from. Two separate fields, and the mismatch between them is often more informative than either alone.
- Creation and modification timestamps, sometimes with a timezone offset that says something about where the machine was.
- Embedded fonts, with the subset tags that reveal how many separate passes wrote text onto the page.
- Revision structure: PDFs can be saved incrementally, appending changes rather than rewriting, so a file can literally contain its own earlier versions.
- XMP: a second metadata block, often left behind by design tools, that survives when the basic fields have been cleaned.
- Encryption and permission flags, and whether the document carries a signature.
What it can support
Three conclusions, stated carefully.
- This file was assembled by hand rather than generated by a system. A statement whose Producer names a design tool or a word processor was not produced by a bank's reporting engine, whatever the page shows. That is a strong, checkable finding.
- This file was saved more than once. Revision layers and a modification timestamp later than creation both establish that the file has a history. In the strongest cases the earlier version is still inside the file and can be recovered — a figure covered by a white box is hidden, not deleted.
- This file is not what it claims to be structurally. When the internal structure does not match the software named in the metadata, one of the two is lying, and that contradiction is itself the finding.
Notice the shape of all three: they are statements about the file's history, not about the truth of what it says.
What it cannot support
- That a document is genuine. Clean metadata is the absence of the easy tells, nothing more. It can be stripped in seconds, rewritten to name any producer you like, or simply never have existed on a file that was fabricated cleanly from the start.
- That an edit was fraudulent. Re-saves happen constantly for innocent reasons: a bank's own portal re-renders the file, an email gateway rewrites it, the applicant's phone re-encodes it, someone adds a highlight. The trace of a second save and the trace of a forgery are the same trace.
- That the numbers are true. Metadata knows how the file was made and nothing about whether the salary on it was ever paid. A perfectly clean file can contain entirely invented transactions.
- That a signature makes it trustworthy. A digital signature proves the bytes have not changed since it was applied and, if the certificate chain is sound, who applied it. It says nothing about whether the content was accurate before signing — and most banks do not sign statements at all, so its absence proves nothing either.
The asymmetry that makes it useful anyway
Metadata is strong evidence of manipulation and weak evidence of authenticity. That asymmetry is not a flaw; it is what makes it worth reading first. A finding costs you three minutes and eliminates a document. A clean read costs the same three minutes and eliminates nothing — it just moves you on to the checks that can.
Used that way it is a filter, not a verdict. Used the other way — "the metadata is clean, so we accepted it" — it is worse than skipping the check, because it manufactures a confidence that has nothing behind it.