PDF Metadata Forensics: A Complete Field-by-Field Reference

Every PDF file carries two layers of information. The first is the visible content – the text, images, and layout a reader sees. The second is metadata: structured data describing the document itself. This second layer records when the document was created, which application produced it, whether it has been modified, and by what tools.

Forensic analysis of these fields can reconstruct a document’s history without examining its visible content at all. For document fraud detection professionals, understanding each field – what it stores, what it reveals, and what makes a value suspicious – is the foundation of PDF authenticity assessment.

This reference covers every major metadata field used in PDF forensics, the structural record of how the file was saved (the cross-reference table), and how these signals combine into an overall authenticity verdict.

Two Metadata Systems in One File

Modern PDF files contain two distinct metadata systems that coexist and sometimes conflict.

The DocInfo dictionary is the original system, introduced with PDF 1.0. It stores metadata as plain text key-value pairs inside the PDF’s trailer structure. Fields like CreationDate, ModDate, Creator, and Producer all live here. It is simple, universally supported, and very easy to edit with basic tools.

XMP metadata (Extensible Metadata Platform) is XML-based and was introduced in PDF 1.4. It stores a richer, more structured version of the same information, plus additional fields that the DocInfo dictionary cannot represent. XMP is embedded as a stream object within the PDF.

When both systems are present, they should agree. A document where the DocInfo dictionary says the creation date is 2020 but the XMP stream records 2024 has an internal inconsistency – a strong indicator that one of the two was modified manually after the original export.

HTPBE? reads both systems and flags contradictions between them as a distinct finding.

To see both systems for one of your own files, open it in the free PDF metadata viewer – it dumps every DocInfo key and the full XMP packet side by side, so you can spot a mismatch like the one above for yourself.

Field: CreationDate

What it stores: The timestamp recorded when the PDF was first written to disk. In the DocInfo dictionary, this is stored in the format D:YYYYMMDDHHmmSSOHH'mm' – for example, D:20220315143022+02'00' represents 14:30:22 on 15 March 2022 in the UTC+2 timezone.

What it reveals: The earliest possible moment the document could have existed. This is the anchor point for all other temporal analysis.

Suspicious patterns:

• CreationDate is today’s date on a document that is supposed to be years old. A bank statement from 2021 with CreationDate: 2026-03-27 was either re-exported from source data very recently or was fabricated.
• CreationDate is in the future. This happens when the PDF-generating machine has its clock set incorrectly, but it is also a byproduct of certain editing tools that do not normalize timestamps.
• CreationDate is significantly earlier than the software that allegedly created it. If Creator reports an application released in 2023 but CreationDate is 2019, one of those values is wrong.

Critical limitation: CreationDate is a plain-text field. Any text editor or command-line tool can change it to any value. It is not cryptographically protected. It should be treated as a claim, not a fact, and checked against other signals.

Field: ModDate

What it stores: The timestamp of the last modification to the PDF. Like CreationDate, it uses the same D: format. ModDate is updated by any operation that saves changes back into the file: editing content, adding annotations, applying a digital signature, running an optimizer, or converting with a new tool.

What it reveals: When the document was last processed by any application. A significant gap between CreationDate and ModDate on a document that was never supposed to be touched after creation is a core forensic signal.

The normal case – digital signatures: Applying a digital signature counts as a modification and updates ModDate to the signing timestamp. A payslip issued on the first of the month and signed by the employee for submission on the fifteenth will show CreationDate two weeks before ModDate. This is completely expected. A later modification date is therefore not, by itself, evidence of editing; HTPBE? reads it together with the rest of the file.

Suspicious patterns:

• ModDate is years after CreationDate on a document that is supposed to be a static official record (a diploma, a property title, a tax certificate). The gap itself is not proof of fraud, but it warrants investigation into what tools produced the modification.
• ModDate predates CreationDate. This is logically impossible and indicates deliberate tampering with one or both timestamps.
• ModDate matches the timestamp of a known online editing service, while CreationDate matches the original institution’s software.

What HTPBE? checks: The gap between CreationDate and ModDate is one input. It is read together with the file’s save history and structure, and neither a large gap nor a small one decides the verdict by itself.

Field: Creator (also called CreatorTool)

What it stores: The name of the application that originally authored the document and exported it to PDF. This is distinct from whatever tool later processed or printed the file. For a Word document saved as PDF, Creator would typically be Microsoft Word. For a report exported by an enterprise platform, it is usually the name of that platform’s reporting component.

ISO 32000 standard semantics: The ISO 32000 specification (maintained and published by the PDF Association) defines Creator as the name of the application that created the original document, and Producer as the name of the application that converted or last processed the file. Creator represents origin, not editing history. Producer is the field that should be updated to reflect processing tools. For where that standard came from, see the history of PDF.

Why Creator is worth reading: Institutional documents – bank statements, payslips, university transcripts, government certificates – are usually generated by specialised software. If the Creator names a general-purpose design or office tool instead, that is a question to put to the sender, not a verdict. The field is a claim that the saving software wrote about itself, and it can be overwritten like any other metadata.

Field: Producer

What it stores: The name of the application that most recently processed or converted the PDF. Where Creator represents origin, Producer represents the last tool in the processing chain. If a Word document is opened in Adobe Acrobat Pro and re-saved after adding a comment, Creator remains Microsoft Word and Producer becomes Adobe Acrobat Pro DC 2024.002.20991.

ISO 32000 standard semantics: Unlike Creator, which should remain stable, the Producer field should be updated by each tool that processes the file. This means Producer gives a running record of the last tool to touch the document.

Reading the pair: Creator and Producer often differ for ordinary reasons: a word processor hands its output to a PDF library, a browser prints a web page, a conversion tool rewrites a file. A difference between the two is a reason to look closer, not a finding. Neither field proves who made the document or whether it was changed, because both are text that software writes about itself. Whether a file has been edited is decided from its structure, not from these two strings alone.

XRef Tables (Cross-Reference Tables)

What they are: The cross-reference table is the PDF’s internal index. It maps every object in the file (pages, images, fonts, metadata streams, signatures) to its byte offset within the file. Without the xref table, a PDF reader cannot locate any object.

When a PDF is first created and saved, a single xref table is written. When the PDF is subsequently modified and saved again, PDF’s default behavior is incremental saving: rather than rewriting the entire file, a new section is appended to the end of the file, and a new xref table is appended that describes only the changed or added objects. The previous xref table remains intact.

This means xref_count – the number of xref sections in a file – gives a rough count of the saves still recorded in the file.

xref_count: 1 — No later saves are recorded in the file. On its own, that says nothing about what happened to the document before it was last written.

xref_count: 2 — The document was saved a second time. Signing is one common reason for that; the count alone does not say which.

xref_count: 4 — The document has been through four save operations. That is worth reading alongside what the document claims to be.

Why the save history is worth reading: CreationDate, ModDate, Creator and Producer are text that can be overwritten in seconds. The save history is part of how the file is put together rather than a label written on it, so it is read alongside the other signals instead of being taken at face value.

Nuances:

• Ordinary operations such as adding comments, bookmarks or form-field values are often saved the same way, so more than one save is not by itself a finding. The number is read in context, not against a threshold.
• A low xref_count on its own does not prove a clean history. It is one signal among several, read together with the others.

HTPBE? reports xref_count and the file’s producer in the API response. To see how those save points chain together and how to read them by hand, see how to view a PDF’s edit history.

Empty or Stripped Metadata

Absent metadata is itself a forensic signal, but it is ambiguous.

When empty metadata is suspicious: Documents from established institutional systems normally carry populated metadata. When a document that claims that kind of origin has none, it is fair to ask why, because general-purpose tools can remove these fields. It is a question for the issuer, not proof of fraud.

When empty metadata is common: Files built directly by code often carry little or no metadata, because many programming libraries leave these fields empty unless told otherwise.

How HTPBE? handles it: Missing metadata is never read as a clean result. HTPBE? reads it together with the rest of the file.

Digital Signatures and Their Interaction with Metadata

A digital signature in a PDF protects the content of the document at the moment of signing. Any subsequent modification to the signed content will invalidate the signature. This sounds comprehensive, but the implementation details matter.

What signing does to metadata: When a signing application (Adobe Acrobat, DocuSign, a custom signing service) applies a signature, it appends a signature object to the PDF and writes a new xref section. ModDate is updated to the signing timestamp, and Producer may change to name the signing software. A signature explains that later save; it does not vouch for what the file contained before it was signed.

The Incremental Saving Attack: Research published at pdf-insecurity.org documented a class of vulnerabilities in PDF signature validation. In some older or misconfigured PDF viewers, it is possible to append additional content to a signed PDF in a new incremental update. The signature validation reports the signature as valid – because the signed content has not changed – but the document as displayed to the user includes the appended content, which was never signed.

In practical terms: a signed document can have additional pages appended, additional form field values inserted, or visual overlays added in a new xref section, and a naive signature validation tool will still report the signature as ‘valid.’

What HTPBE? detects: HTPBE? can tell whether content was added to a file after it was signed, whatever a signature validator reports about the signature itself.

Reading the Fields Together

No single combination of these fields settles the question. Each one is read alongside the rest of the file and against what the document claims to be.

Why No Single Field Is Conclusive

Each field in this reference has a legitimate explanation for values that look suspicious in isolation. A future CreationDate might be a server clock configuration error. A Producer from an online editor might mean the recipient printed and re-uploaded the document for their own filing. A large xref count might come from legitimate document management workflows.

The forensic value comes from the combination. A document that claims to be years old but was made today in general-purpose design software tells a different story from its own claim; a file saved repeatedly long after it was issued tells another. Neither pattern rests on a single field.

HTPBE? combines all of these signals into a verdict (status) supported by the modification_markers array, which lists each specific signal that contributed to the result in plain language, so the analyst can evaluate the evidence rather than accepting a black-box verdict. The same field-by-field reasoning is available programmatically through the PDF metadata forensics API, which returns every field discussed here alongside the verdict. For when reading the fields is enough and when it is not, see PDF metadata viewer vs file-history check.

Conclusion

PDF metadata forensics is not about finding a single smoking gun. It is about reading a document’s history from the fields that institutions, editing tools, and the PDF format itself leave behind. CreationDate and ModDate establish the temporal frame. Creator and Producer name the software that claims to have made and last written the document. The xref table records how many times it was saved. Each field is a claim; the combination of claims either tells a coherent story or reveals contradictions.

Understanding these fields individually is the prerequisite for interpreting them collectively. When the story they tell matches the document’s claimed origin, there is no contradiction to explain – which is not proof that the document is genuine. When they contradict each other – or contradict what the document claims to be – that is evidence worth investigating.

Related FAQ: What is PDF metadata, and why does it matter? · What is the difference between Creator and Producer in a PDF? · Why does my PDF show a creation date in the future?

Once you can read the fields, has this PDF been edited? five ways to check shows which method fits which kind of document and the common mistakes in checking by hand.