Can a PDF's Creation Date Prove Anything? Not on Its Own

No, not by itself. The line in a properties dialog that reads, say, "Created: 12 March 2024" is a field inside the file, written by whichever program produced the PDF, and nothing in that file ties the value to an independent clock. Metadata can support a case you are already building from other facts. It cannot carry one.

Key Takeaways

• CreationDate and ModDate are ordinary fields written by the producing software, not observations recorded by a neutral party.

• The "Created" date in Windows or macOS belongs to the copy on your disk and changes when a file is downloaded, copied or restored.

• Both sets of dates can be rewritten in seconds by anyone holding the file, which is why an opponent can dismiss them in one sentence.

• There is no second, hidden set of metadata that Adobe keeps in reserve. That belief surfaces in forum threads year after year, and it is wrong.

• Under eIDAS Article 41(2), only a qualified electronic time stamp enjoys a presumption of the accuracy of the date it indicates (legislation.gov.uk).

A file's creation date is written by the machine that produced it, so whoever controls that machine controls the date it reports.

What does a PDF actually store about its own age?

Two sets of dates, kept in two places, which do not have to agree. The first lives in the document information dictionary, a small block of key-value pairs holding fields such as Title, Author, Producer, CreationDate and ModDate. The second lives in an XMP metadata stream, a separate packet of structured text that many producing applications also write. Both belong to the PDF format itself, standardised as ISO 32000-1, the version the Dutch government lists under its comply-or-explain regime (Forum Standaardisatie).

Neither block records events. They hold values the writing program chose to put there, usually by asking the operating system what time it was. A scanner fills them differently from a word processor, and some tools barely fill them at all. The field looks like a fact about the past. It is closer to a claim software made about itself.

Why doesn't the file date in Windows or macOS help?

That date describes the copy in front of you rather than the document. Windows file properties and Cmd+I on a Mac report timestamps maintained by the file system: created, modified, last opened. They belong to that copy on that disk. Download the same attachment twice and you get two different creation dates. Copy a folder to an external drive, restore from a backup, sync it through a cloud client, and the values move again.

Confusion between the two kinds of date runs through almost every discussion of this subject. People spot a difference between the date inside the PDF and the date the operating system reports, then conclude that someone tampered with the file. Usually it was simply downloaded later than it was written.

How easily can those dates be changed?

Trivially, and that is the whole problem. Free, well-documented command line utilities rewrite the document information dictionary and the XMP block in a single instruction. We are not going to print the syntax, because a working recipe helps the wrong reader. What matters for your file is that the operation takes seconds and leaves no bruise.

There is a blunter route that touches no metadata at all. The clock the producing software asks for the time is the writer's own clock, so a file can be genuinely written with a date of the writer's choosing, by ordinary software behaving normally. Nothing is edited afterwards, which is one reason forensic attention to the file itself so often comes up empty.

When opposing counsel says the date proves nothing, they are describing the format accurately.

Does Adobe keep a second, hidden set of metadata?

No. This is the most persistent misunderstanding in the field. In a 2019 thread from someone who believed a former employer had produced a backdated employment contract, the answer was direct: there is no second, hidden metadata, and all metadata is editable. A PDF is a document format rather than an audit system, and it was never designed to testify against the party that wrote it.

Why does identical content produce different metadata, and different content the same metadata?

Because the dates track the act of writing a file, not the act of drafting a document. Export the same contract twice from the same word processor and you get two PDFs with different creation dates and identical text. Open a five-year-old template, change one clause and save: the fields may still point at the template's origin, because plenty of libraries never update ModDate.

Automated pipelines add another layer. In a 2024 case before the Dutch Council of State, a signed measure was sent to the judiciary, where the file was converted to a format for digital archiving. The ruling records that this conversion damaged the part of the file where the electronic signature sat, so the version in the case file failed validation while the original validated normally (ECLI:NL:RVS:2024:4237). Nobody edited anything. A routine archiving step rewrote the bytes.

What we learned when we tried to hash metadata

We met that instability from the other side while building. The idea was simple: produce a stable fingerprint of a document's metadata, so two parties could compare results without exchanging the file itself. The first version returned a different hash on every run.

The reason sat in the output. The extraction timestamp was in there, along with the filename and the version of the engine that read the file. None of those describe the document; they describe the moment you looked at it. Only after stripping them did the same document hash the same way twice. Our fingerprint tool still keeps file, text, visual and metadata hashes apart for that reason. They answer different questions and they fail in different ways.

When is metadata worth looking at at all?

Metadata earns its place as a supporting signal, read alongside facts that came from somewhere else. Dutch civil procedure helps here: under Article 152 Rv evidence may be brought by any means, and its weight is left to the judge. Admissibility is not your obstacle. Persuasion is.

Look at how backdating is actually established. In a 2021 case, the Rotterdam District Court found that care agreements were partly backdated and therefore falsely drawn up (ECLI:NL:RBROT:2021:5027). That finding rested on substantive inconsistencies in the documents and on statements, not on metadata or forensic file examination. The court reached its conclusion by a different road entirely.

Where technical examination does take the lead, it often disappoints. In a matrimonial property case decided in February 2026, an investigation report saw strong indications that disputed emails from 2008 and 2014 had been manipulated. The Hague Court of Appeal still could not establish who had falsified them (ECLI:NL:GHDHA:2026:180).

Meanwhile the downside risk is asymmetric. Under Article 159(2) Rv, an underhand deed whose signature is firmly denied carries no evidentiary force until the origin of that signature is proved, and the Supreme Court applied that rule in April 2019 (ECLI:NL:HR:2019:572). One sentence from the other side can cost you the document. A metadata field will not win it back.

What does Adobe Acrobat tell you, and what does it leave out?

Acrobat reports the file faithfully. That is the limitation rather than a flaw in the software: a reader can only relay what the file claims about itself.

Only the last row brings in a party with no stake in the outcome, and Acrobat expects you to have chosen that party already. Everything above it is the file describing itself.

What does it take to make a date hard?

Someone independent has to have recorded something at that moment. That is the entire difference, and it is why the answer never lies deeper inside the file. European law is explicit about the reward: under Article 41(2) of Regulation (EU) 910/2014, a qualified electronic time stamp enjoys the presumption of the accuracy of the date and time it indicates, and of the integrity of the data bound to it.

Everything below that standard is not worthless. Article 41(1) provides that an electronic time stamp may not be denied legal effect or admissibility purely because it is electronic, or because it falls short of the qualified requirements. What you lose is the presumption. Without it you argue for your date; with it, the other side argues against it.

The requirements themselves sit one article further on. A qualified time stamp must bind date and time to the data so that undetectable change is reasonably precluded, must run on an accurate time source linked to Coordinated Universal Time, and must carry an advanced electronic signature or seal of the qualified trust service provider, or an equivalent method (Article 42). Hold a CreationDate field against those conditions. It meets none of them.

It is worth knowing how such a service actually runs, so here is ours. Hashes of new documents wait for a daily round at 03:00 Europe/Amsterdam, when they are combined into one Merkle tree; only the root hash travels to the qualified trust service provider, Disig a.s. A flat list would force us to hand over every other document's hash in that batch; the tree avoids that. The qualified time stamp leaves the stored PDF byte for byte identical, and the proof is kept for twenty years, independently of the file's own retention. Anyone can check a document against that chain at /verify.

Even then, the honest phrasing is narrow. An independent record establishes that a file existed no later than a given moment. It says nothing about who wrote it, whether the content is true, or whether it existed earlier. Time stamps are one route among several; we compared the trade-offs in how to prove a document existed on a date.

Frequently asked questions

Can I tell from the metadata whether a PDF has been edited?

Not reliably. Matching creation and modification dates guarantee nothing, because both fields accept any value and plenty of tools never update the second one. Structural traces inside a file may show that it was rewritten. They cannot tell you whether the figures on page three are correct.

If the creation date and the modification date are identical, is the file original?

No. Identical dates are what a fresh export looks like, and also what a careful rewrite looks like. Many tools never touch the modification field at all. Sameness proves nothing in either direction.

Can you just change the creation date of a PDF?

Yes. Freely available metadata utilities rewrite the field, and a file can equally be produced with whatever date its writer's clock reports, which leaves nothing to edit afterwards. We deliberately do not publish the method. What matters in your case is that the other side can do it, and can say so.

How do I prove that a contract was backdated?

Rarely through the file. In the Rotterdam case above, backdating was established through inconsistencies in the content of the agreements and through statements, not through examination of metadata. Treat metadata as something that may corroborate a picture built elsewhere.

Can the sender still change a PDF after sending it to me?

Not the attachment sitting in your mailbox. People convinced that a document changed remotely have usually met a fresh download overwriting the old file, or a cloud document that was never a static attachment. The real difficulty runs the other way: you cannot show from the file alone that it is still the one that was sent.

Start by reading what your own file says

If you are holding a document whose date matters, start by seeing what the file actually contains: the document information fields and the XMP block, not the two lines a properties dialog summarises. The PDF metadata viewer shows those fields in the browser, without an account. For exports, email trees and API access, the full metadata tool covers the same ground; that one needs an account and costs a credit per file.

Neither detects forgery. No tool that reads only the file can, and one claiming otherwise deserves a second look. Once you see how thin the file's own assertion is, you are asking the better question: who else recorded something at that moment?

Daan van Tongeren is the founder of PDFen, where he built the document fingerprint and qualified time stamp chain described here.