See every earlier version saved inside a PDF STRATA

A PDF keeps its own history, and the reader hides it

A PDF can be saved by appending. The objects that changed are written after the existing file, followed by a new cross-reference section whose /Prev points back at the old one. Nothing earlier is removed. A form that was filled in, a comment that was deleted, a paragraph that was rewritten, a page that was replaced: all of it is still in the file, under the newest version, and every reader shows you only the newest.

That is not a bug in the readers. It is what an incremental save is for, and it is what makes signing a PDF possible at all: the signature covers a byte range, and later changes go after it so the earlier bytes stay signed. It is also why documents are so regularly sent out with their revisions intact, by people who redacted something, saved, and reasonably assumed that saving removed it.

Why the bytes are read by hand

Ordinary PDF libraries cannot show you this, and not through neglect. They are built to hide it: read the newest cross-reference, repair whatever is broken, hand over one coherent document. That is exactly right for displaying a page and exactly wrong for finding out what the file used to say.

So this walks the chain in the bytes. It finds startxref, follows each section's /Prev, handles classic cross-reference tables and cross-reference streams alike, and reads /XRefStm for a hybrid file. Each version ends where its own startxref and %%EOF were written, and every startxref in the file is a candidate boundary only if the section it names is in the chain the file stands on today and that section's own chain stays inside the cut. The second test is what stops a linearised file, which carries two cross-reference sections for a single version with a /Prev pointing forward, from being counted twice, and stops a PDF embedded inside another from being mistaken for the outer file's history.

What is compared between one version and the next

For each consecutive pair: the document properties and the XMP packet, the fonts each page uses, every page's decoded content stream, the annotations on it, the form field values, the signatures and how many bytes each one actually covers, and a rendering of every page at the same scale compared pixel against pixel.

The last two are the ones that decide arguments. A signature that covers fewer bytes than the file contains is a signature with material appended after it was applied: the document was signed and then added to, which looks entirely normal in a reader. And the pixel comparison catches what a structural diff cannot describe: a figure replaced, a number changed inside an image, a stamp moved.

Nothing is uploaded, which matters more here than for most tools: the documents worth examining this way are contracts, disclosure bundles, reports and statements, and those are precisely the files that must not become somebody else's HTTP request. Alongside it, LINEAGE reads the editing history a Word file keeps about itself, SCRUB and FLATTEN remove the history before a document goes out, and PROVENANCE records that the copy you examined is the copy you were given.