How to Check a PDF’s Creation & Modification Dates

Every PDF carries two dates: when it was created, and when it was last saved. Open any file’s properties and you’ll find both in seconds. Both are plain text, the same kind of string as the title or the author name. Any editor that can open a PDF can rewrite them to say whatever the person editing wants.

That doesn’t make the dates useless. It makes them a claim rather than a fact. Checking a PDF’s dates properly means knowing the difference between reading them and trusting them.

Where the two dates live

The Info dictionary, a small block of metadata in the file’s trailer, can carry a CreationDate and a ModDate field. Many PDFs duplicate the same two values in an embedded XMP packet (xmp:CreateDate and xmp:ModifyDate), a second, XML-based metadata layer that Adobe tools and some other generators write alongside the Info dictionary. Both live inside the file itself, not in your filesystem. They travel with the PDF when you email it, upload it, or copy it to a new folder. For the full field-by-field breakdown of the Info dictionary, including Creator, Producer and the xref table, see PDF metadata forensics: a complete field-by-field reference. This article stays on the two date fields.

CreationDate records when the document was first generated: the moment the PDF bytes were written, not necessarily when the underlying content (a scanned page, a report’s source data) came into existence.

ModDate records when the file was last saved. Any operation that writes changes back into the file updates it: editing text, adding a digital signature, filling a form field, running the file through a compressor or format converter.

On a document generated once and never touched again, the two should match, or come close enough that the gap is meaningless.

How to check a PDF’s creation date online or offline

You don’t need any special software for a quick look.

In Adobe Acrobat Reader: open the file, then File → Properties. The Created and Modified fields are on the Description tab.

On Windows: right-click the file, choose Properties, and check the General tab.

On macOS: right-click the file, choose Get Info, and check Created and Last Modified. Finder sometimes shows filesystem timestamps rather than the values embedded in the PDF, so don’t treat what you see there as forensic-grade.

Online, without opening a desktop app: a metadata viewer that reads the file’s actual Info dictionary and XMP packet, rather than your OS’s file-manager timestamps, is more reliable. Our free PDF metadata viewer dumps every field from a file you upload — both dates, Creator, Producer, and the rest — with no account required.

Whichever method you use, you’re reading the same underlying bytes. The question is what those bytes are worth.

Why the raw values lie

CreationDate and ModDate are stored as plain-text strings in a format that looks like D:20260115093000+02'00'. There is nothing cryptographic about them. No hash, no signature, no tamper-evident seal. A text editor, a command-line metadata tool, or any PDF editor’s “document properties” panel can rewrite either field to any value at all, and the file opens normally afterward with no warning that anything changed.

So a mismatch, or a suspiciously round number (“created” at exactly midnight, or matching today’s date on a document that claims to be years old), is not proof of fraud. A match between the two dates is not proof of an untouched file either. Someone forging a document can set both fields to whatever they want, including making them identical to hide the edit.

Read alone, the two dates tell you one honest thing and one dishonest thing. The honest thing: if they genuinely differ, something wrote to the file after it was first created. Any real save operation produces that as a byproduct. The dishonest thing: the exact values are self-reported by whatever software last touched the file, and nothing stops that software, or a person with a text editor, from writing false ones.

This isn’t a theoretical weakness. General-purpose metadata utilities exist specifically to read and rewrite these fields. That’s their entire job, and it’s a legitimate one for privacy scrubbing before you share a file. The same capability that lets you strip your name from a PDF before sending it to a stranger lets someone backdate a document by five years with one command. The field doesn’t know, or care, which use case it’s serving.

What a plain glance at the dates can’t tell you

Two documents can carry identical, perfectly plausible CreationDate and ModDate values and still be nothing alike underneath. A bank statement generated once by an institutional system and a bank statement built from a template, with the balance changed and the dates manually reset to look consistent, can present the exact same two numbers in Properties. The dates report what the last piece of software claimed. They carry no information about whether that claim is true.

This is the gap between “checking a PDF’s dates” and “verifying a PDF’s dates.” Checking is reading the two fields. Verifying means asking whether the rest of the file’s structure — how many times it was actually saved, what software produced it, whether a signature or format conversion accounts for any gap — is consistent with the story the dates are telling. A forger who resets both fields to match still leaves the save history, the producer fingerprint, and the cross-reference structure largely as they found them. Rewriting those convincingly takes more than a metadata editor.

Gaps that are normal, and gaps that aren’t

Not every difference between CreationDate and ModDate means someone tampered with the document. Several ordinary workflows produce a real, legitimate gap:

• Signing in the same sitting. Open a document, sign it, save it. That whole sequence can land within a few seconds of CreationDate, because applying a signature is itself a save operation.
• PDF/A conversion. Archival-format conversion rewrites the file’s structure even when the visible content doesn’t change, which updates ModDate. The file genuinely was re-saved, and the conversion is a real reason for it.
• Batch or scheduled report generation. Some generation engines set CreationDate when a document template or job is defined and only stamp ModDate when the specific instance is rendered and saved. The gap reflects two pipeline stages, not anyone opening and editing content afterward.

A benign reason for a gap explains it; it doesn’t erase it. If a file was reopened and re-saved days or weeks after it was first created, for a signature or a re-export, that is a real event in the file’s history, and a structural check surfaces it as one. Whether the event matters for your workflow is your judgment call. The tool’s job is only to report that the write happened.

What a structural check adds

HTPBE?’s detection algorithm doesn’t stop at comparing two numbers. A few things it evaluates that a manual glance at Properties can’t:

A tolerance for legitimate imprecision. Some PDF generators set CreationDate when a document workflow starts and ModDate a fraction of a second later when the render completes. That gap is real but meaningless. HTPBE? treats dates within 15 seconds of each other as the same timestamp, so it doesn’t fire a false alarm on that kind of engine behavior. A meaningful gap beyond that window produces the HTPBE_DATES_DISAGREE marker.

Cross-checking the two metadata layers against each other. When a PDF carries both an Info-dictionary date and an XMP date for the same event, they should normally describe the same moment. A disagreement usually means one layer was edited independently of the other — a partial edit that a manual check of one field misses entirely. That produces HTPBE_TIMESTAMP_LAYERS_DISAGREE.

Catching physically impossible values. A creation date decades before the PDF format existed, or a date meaningfully in the future, isn’t a normal software quirk. No generator legitimately produces it. That’s HTPBE_IMPOSSIBLE_TIMESTAMP.

HTPBE? still checks the file’s broader structure first — how many times it was actually saved, what software last touched it — because a verdict rests on the whole file, not a single field. A full list of what each marker checks for is in the forensic checks catalog.

Reading a structural result

Submitting a PDF to the HTPBE? API returns both raw date fields and the algorithm’s read on them as structured JSON. An abridged slice of the response, showing only the date-relevant fields:

{
  "id": "506a6b1b-1360-48a2-b389-abb346f85d04",
  "status": "modified",
  "modification_confidence": "certain",
  "modification_markers": ["HTPBE_DATES_DISAGREE"],
  "creation_date": 1704110400,
  "modification_date": 1707840000,
  "creator": "Adobe Acrobat Pro DC",
  "producer": "Adobe PDF Library 15.0",
  "usage_caution": {
    "safe_for_automated_adverse_decision": false,
    "recommended_action": "route_to_human_review",
    "message": "Structural evidence of post-creation modification was found. Route this document to a human reviewer before any decision — do not use this verdict as the sole basis for an automatic adverse decision against a person."
  }
}

creation_date and modification_date are Unix timestamps in seconds, here roughly 43 days apart, far beyond the 15-second tolerance. modification_confidence: "certain" reflects that this is consistent with a genuine post-creation write. usage_caution is present on every response as a reminder that a file-level finding should route to review, not drive an automatic decision about the person who submitted it. The full response schema, including every field this endpoint returns, is documented at /api.

Common questions

Can a PDF’s creation date be changed after the fact? Yes, trivially, with any of several free metadata-editing utilities or a hex editor. That’s why the date fields alone are a claim rather than evidence.

Does printing a PDF or converting it change the dates? Printing to a physical printer doesn’t touch the file’s metadata. Converting a file — re-saving from one format to another, running it through an optimizer — almost always updates ModDate, because the conversion tool writes a new file. The file you’re looking at isn’t byte-for-byte the one that was first generated, and a structural check reports that write either way. “Print to PDF” is a separate case: it produces a file with no PDF-editing history to find at all, and the honest verdict for that is inconclusive, not a clean bill of health.

Why does my PDF show a creation date in the future? A timestamp slightly ahead of the current time is usually clock drift on the machine that generated it. Hours or days out is a different matter. We cover this specific case in more depth in why does my PDF show a future creation date.

Do matching dates prove a PDF wasn’t edited? No. Some generators set both fields to the same value on export regardless of what happened before, and anyone editing a file with a metadata tool can reset both to match on purpose. Matching dates are consistent with an untouched file; they aren’t proof of one.

I need the number of times a file was actually saved, not just whether the dates differ. That’s a different question, answered by the file’s revision chain rather than its date fields. See how to view a PDF’s edit history for how to read that separately.

I want the full checklist, not just the date fields. Has this PDF been edited? Five ways to check covers metadata alongside visual inspection, signatures, and automated tools. This article stays on the date fields because they’re the check most guides get wrong.

A short checklist

For a single file, right now:

1. Open the document properties (Acrobat, OS file properties, or a metadata viewer) and note both dates.
2. If they match exactly, that’s consistent with an untouched file, not proof of one.
3. If they differ, look for a plausible explanation — a same-sitting signature, a format conversion, a template-vs-instance report pipeline — before assuming the worst. The explanation doesn’t erase the write.
4. For anything that needs a verdict rather than a guess — a loan application, a signed contract, a submitted invoice — run a structural check. Plausible-looking dates on a forged document prove nothing about the rest of the file; a structural check evaluates them alongside everything else the file’s bytes reveal.

None of that scales to a queue of applications, contracts, or invoices, and a reviewer scanning Properties by hand won’t catch a date pair a forger reset to look clean. That’s a job for an API call. The HTPBE? API returns creation_date, modification_date, and the full modification_markers array on every request. Register for 5 free checks and a free test API key, so you can run the endpoint against synthetic documents before pointing anything at production files. The entry plan runs 30 checks a month from there, and current pricing covers the higher tiers.