What is PDF metadata and why does it matter for authenticity?
PDF metadata is the information a PDF file stores about itself: its title, author, the applications that made it and its timestamps. It matters for checking a document because it is the file’s own account of where it came from – useful as a starting point, but never proof on its own.
Where metadata lives in a PDF
A PDF can store descriptive data in two places, and the two do not always agree.
- The Info dictionary is the older, simple record. Its standard fields are Title, Author, Subject, Keywords, Creator, Producer, CreationDate and ModDate. Dates are stored in a compact format with a time-zone offset, which is why raw values look like
D:20240312094500+02'00'rather than a readable date. - XMP is a block of XML embedded in the file. It repeats much of the same information (creation and modification dates, the creating tool, the producer) and can add more: a document identifier, a record of earlier versions, and fields written by specific software. Many modern generators write both; some write only one.
- The PDF version in the file header (for example 1.4 or 1.7) is also part of the picture, although it describes the file format rather than the document.
The Creator and Producer fields are easy to mix up; the difference is covered in Creator vs Producer in PDF metadata.
Reading a raw date, step by step
The Info dictionary stores a date as text. Take D:20240312094500+02'00'. After the D: prefix come year 2024, month 03, day 12, hour 09, minute 45, second 00. The +02'00' at the end says the clock that wrote it was two hours ahead of UTC. So the file says it was written on 12 March 2024 at 09:45 local time, which is 07:45 in UTC. Dates in HTPBE? results are shown in UTC so that two files from different time zones can be compared directly. A date with no offset at all is common and means the writer did not say which zone it used.
The fields, side by side
- Info dictionary: Title, Author, Subject, Keywords, Creator, Producer, CreationDate, ModDate.
- XMP equivalents:
xmp:CreateDate,xmp:ModifyDate,xmp:CreatorTool,pdf:Producer, plus identifiers such asxmpMM:DocumentID.
How to view the metadata of a PDF yourself
- Adobe Acrobat or Reader: open File → Properties. The Description tab shows title, author, creation and modification dates, the creating application and the PDF version.
- macOS Preview: Tools → Show Inspector shows the general document properties.
- Command line:
pdfinfo file.pdf(Poppler) prints the Info fields, andexiftool file.pdfprints both the Info fields and the XMP data. - Online: the free PDF metadata viewer shows every Info field, the full XMP data and the technical facts of the file without installing anything.
Desktop viewers usually show a tidied subset. If you need the raw values, the XMP data included, use a tool that prints them in full.
Why metadata matters when you check a document
- It shows what produced the file. A bank statement that claims to come from a bank’s statement system but names a consumer image editor as the producing application is worth a closer look. A payslip exported by payroll software is less surprising.
- It carries a timeline. A creation date and a modification date place the file in time. They can be compared with the date printed on the document and with when it was supposedly issued.
- It can show that a file was saved again. Editing and re-saving usually leaves traces in these fields.
- It is quick to read. Looking at metadata takes seconds and needs no original to compare against.
What metadata cannot tell you
Metadata is information the file states about itself, and it is not protected. Anyone can rewrite or delete these fields with free tools in a few seconds, so treat them as claims, not evidence.
- Clean-looking metadata does not mean unedited. Dates and tool names can be set to anything, and a file can be edited and then given tidy-looking fields.
- Odd or missing metadata is not proof of tampering on its own. Many legitimate workflows strip metadata on purpose: privacy tools, email gateways, document-management systems, scanners, print-to-PDF drivers and some online converters. Empty fields alone do not tell you which of these happened.
- A modification date does not say what changed. It records that the file was saved at some point, not whether the change was a correction, a form being filled in, a signature being added or an alteration of the content.
- Metadata says nothing about the content. It does not tell you whether the amounts, names or dates on the page are true.
For that reason, metadata is one input to a check, not a verdict. A reliable conclusion needs the evidence in the file’s structure as well, such as how it was saved over time (see incremental updates in PDF files) and whether any digital signature still holds.
Metadata you may be sending without knowing
The same fields that help a reviewer can expose more than you intended when you send a PDF to someone else. Author is often the account name of whoever installed the software. Title can be a working file name or an internal project code. Creator and Producer reveal which software and version you use. Dates reveal when the file was made, which can be long after the date printed on the page. If a document leaves your organisation, check the properties first and remove what should not travel; a fresh export from the source system usually carries less than a file that has been edited several times. Stripping fields from a finished file creates a new file, which a later check can report as changed.
A three-question read of any file’s metadata
- Does the producing software fit the kind of document it claims to be?
- Do the creation and modification dates fit the date printed on the document?
- Is anything empty, and does a known step in the file’s journey explain it?
Answering these takes a minute and gives you a list of questions for the sender. It does not give you a verdict.
When this does not apply
A scan or a photo saved as PDF often carries only the scanner or app name and a date, because there is no authoring software behind it. A file passed through an email gateway or a document-management system may have its fields rewritten on the way. In both cases the metadata describes the last tool to touch the file, not the document’s origin.
How HTPBE? uses metadata
HTPBE? reads the metadata together with the structure of the file and returns one of three results: Intact, Modified or Inconclusive, along with named findings explaining the result. Metadata is read as context for those findings and never trusted on its own, because it is the part of a PDF that is easiest to change. The difference between reading fields and running a full check is set out in PDF tamper detection vs metadata tools, and the approach is described on the PDF tamper detection page.
To run the check from your own system, the HTPBE? API returns the verdict and findings as JSON. Pricing for both web checks and the API is on the pricing page.
Related questions
Related questions
Keep reading
3 answers
How Detection Works
Creator is the application that authored the document; Producer is the application that wrote the PDF file. They often differ, and that is normal. The pair shows what kind of software is behind a file.
Verifying Specific Documents
Yes, but treat the result as a technical statement about the file, not legal proof. It shows whether the PDF was edited after it was generated. It does not replace a lawyer or a forensic expert for court use.
Privacy, Data & Limits
No. HTPBE? analyses the structure of the file – metadata, structure, signatures and embedded content – not what the document says. It does no OCR and cannot tell you whether amounts, names or dates inside are correct.