Skip to content
WorldofPDFs

Has this PDF been edited since it was made?

A PDF often keeps evidence of its own history. Reading that evidence is easy; knowing what it does and does not prove is the hard part.

The quick answer

To tell if a PDF has been edited, check four things: whether the file contains more than one %%EOF marker, whether its modification date differs from its creation date, whether its hash matches a known original, and whether its text differs from that original. Each clue is suggestive. None, on its own, is proof either way.

The reason it is never quite proof is the same in every case: everything inside a PDF is just bytes, and anyone with the right software can write any bytes they like. What follows is how each clue arises, so you can weigh it properly.

Clue one: incremental updates

A PDF ends with a small table telling a reader where every object lives, followed by the marker %%EOF. Many editors do not rewrite the whole file when you save a change. They append the changed objects to the end, add a new table pointing at them, and write another %%EOF. The original bytes stay exactly where they were, untouched, earlier in the file.

So a file with three %%EOF markers has, very likely, been saved three times. You can check by opening the PDF in a plain text editor and searching for %%EOF, or with a command-line search that counts occurrences. And because the earlier revisions are still physically present, the original version can often be recovered by cutting the file off at the first marker.

The caveats are real. Some software writes two markers on first save as a matter of course, for example when producing a linearised file for fast web viewing. Signing a document legitimately appends an update too. And a full rewrite, which many tools do on every save, leaves exactly one marker whatever was changed. A single %%EOF means the history was not kept, not that there was none.

Clue two: the dates in the metadata

Most PDFs carry a creation date, a modification date and the names of the program that created the file and the one that produced it. A file whose modification date is weeks after its creation date, or whose producer is a different program from its creator, has passed through more than one piece of software.

World of PDF's Privacy Risk Scanner lists every populated metadata field, including both dates and both program names, and reports whether the file also carries an XMP metadata packet, which sometimes holds a second and older copy of the same details. A mismatch between the two copies is itself a clue that one was updated and the other was not.

The limits: these fields are written by software and can be set to anything. A careful editor can set the dates back, and plenty of honest workflows, such as re-saving to fix a font, change them without changing a word. Metadata tells you what the last program claimed. It is a lead, not a finding.

Clue three: the hash against an original

If you have, or can obtain, a copy you trust, a cryptographic hash settles whether the two files are identical. SHA-256 reduces a file to a 64-character fingerprint, and changing one byte changes the result completely. Matching hashes mean the files are byte-for-byte the same.

The catch runs in one direction. Mismatched hashes mean the files differ, but not necessarily that anyone changed the content: opening and re-saving a PDF rewrites dates and producer strings and can reorder its internals, which changes the hash with nothing on any page touched. The PDF Hash tool's Compare mode handles this by computing a second digest from the page text and dimensions, and telling you when files differ in bytes but match in page content.

Without an original, a hash proves nothing on its own. Its value comes from someone having recorded it at a point you trust: in a signed email, a contract annex, a published download page.

Clue four: what the words actually say

When you have two versions and need to know what changed rather than whether, compare their text. Compare PDFs extracts the text of both files and diffs them word by word, striking through removals and highlighting additions, so a changed figure in clause seven stands out at once.

It is a text comparison, not a visual one. A swapped image, a changed colour or a font substitution with identical wording will not show up. For those, the general technique is a visual diff: render both versions to images at the same resolution and compare them pixel by pixel. A scanned document with no text layer needs OCR before a text comparison means anything.

What you can and cannot prove

Each clue is evidence that something happened, never a complete account of what. A file with one %%EOF, matching dates and no original to compare against is not proven unedited. It is simply a file that gives you nothing to go on.

The strong forms of proof all depend on something established before the question arose: a hash recorded at signing, a cryptographic digital signature that a reader can validate, a copy held by a neutral party. If tampering is a real concern for documents you send, record a SHA-256 hash or use a certificate-based signature at the time. Trying to reconstruct integrity after the fact is always weaker.

Frequently asked questions

Can you tell if a PDF has been altered?

Often, but not always. Multiple %%EOF markers, mismatched creation and modification dates, and a hash that differs from a trusted original are all signs. A carefully rewritten file can carry none of them.

What does it mean if a PDF has more than one %%EOF?

Usually that changes were appended as incremental updates rather than the file being rewritten. Earlier versions are often still inside the file. Some software adds a second marker on first save, so two is not conclusive.

Does the modification date prove a PDF was edited?

No. It records when software last saved the file, which happens for harmless reasons too, and it can be set to any value. Treat it as a lead.

Why does the hash change when I only opened and saved the PDF?

Saving rewrites metadata such as the modification date and producer, and may reorder internal objects. The bytes change even though the pages do not.

How do I prove my PDF has not been changed later?

Record its SHA-256 hash somewhere trusted when you send it, or apply a certificate-based digital signature. Either gives you a fixed point to compare against later.

Tools mentioned in this guide