Find what actually changed between two versions of a PDF

"Is this the same contract they sent last week?" is a question with a precise answer, and most people reach for the imprecise method: reading both documents and hoping. There is a better order of operations.

Step one: are they the same file at all?

Before comparing content, establish whether there is anything to compare. A cryptographic hash answers this instantly and unambiguously.

The fingerprinting tool computes a SHA-256 digest of the file. Two rules follow:

• Identical fingerprints mean identical files. Every byte matches. There is no change anywhere — not in the text, not in the metadata, not in a hidden attachment. You can stop.
• Different fingerprints mean the bytes differ. That is all it means. A single altered character and a completely rewritten document produce equally different hashes, and so does re-saving the same document in a different reader.

That second point catches people out. Hashes prove identity, not similarity. They are perfect for "has this file changed since I signed it?" and useless for "how much has it changed?"

This makes fingerprinting the right tool for a specific and valuable job: record the hash of a document at the moment you approve, sign, or receive it, and you can prove later that the copy in your hands is the same one. Store the hash somewhere the document is not — an email to yourself, a ticket, a register.

Step two: what changed in the words?

For wording changes, compare the text. The comparison tool extracts the text layer from both documents and aligns them, so you see insertions, deletions, and modifications rather than a wall of unchanged paragraphs.

Text comparison is what you want for contracts, policies, specifications, and anything where a single clause matters. It is precise about the thing that matters most: did the wording change, and where?

Its blind spots are real, though:

• It cannot see changes inside images, including scanned pages and screenshots.
• It cannot see layout, spacing, or pagination changes.
• It will report differences caused purely by re-flowing, which are noise.
• A change of typeface or colour is invisible to it.

If one of the documents is a scan, there is no text layer to compare. Recognise it first, and expect a noisier diff, since recognition errors appear as differences that are not really there.

Step three: what changed on the page?

Visual comparison renders each page of both documents and highlights the pixels that differ. This catches everything text comparison misses: a moved logo, an altered chart, a changed figure inside a screenshot, a different signature image, a shifted table border.

Its own blind spot is the mirror image: it is extremely sensitive to trivial differences. A version generated by a different renderer, at a different resolution, or with slightly different font hinting will show differences on every page while the content is identical.

The practical approach is to run both. Text comparison tells you whether the words changed; visual comparison tells you whether the page changed. Serious alterations usually show in one and not the other, which is exactly why one method is not enough.

Step four: look where the page does not show

Two pages can render identically and still differ in ways that matter:

• Metadata. Author, producer, and modification timestamps change even when content does not — often the first clue about who touched a file and when.
• Form field values. A filled field can display a value that differs from the value stored underneath it.
• Annotations. Comments and markup may be hidden or not printed by default.
• Embedded attachments. A file can carry other files inside it.
• Incremental update history. PDFs can be modified by appending to the file, which leaves earlier revisions physically present in the bytes.

Running the text extraction tool over both documents and diffing the raw output is a quick way to catch content that exists in the file but is not visible on the page — text placed off the edge, under an image, or in a hidden layer.

Doing this without uploading either version

Comparison is the task where uploading is least defensible, because you are almost always dealing with two versions of a document that is under negotiation or under review. Handing both to a third party discloses not just the content but the direction of travel: what one side wanted changed.

All three operations — hashing, text comparison, visual comparison — are ordinary computation that a browser can perform on files you select from disk. Neither version has to leave your machine for you to learn what changed between them.

A routine worth adopting

1. Fingerprint every document at the moment you approve or sign it, and record the hash separately from the file.
2. When a new version arrives, fingerprint it. If it matches, you are done.
3. If it does not match, run a text comparison and read every reported change, including the ones that look cosmetic.
4. Run a visual comparison for anything containing images, charts, or scanned content.
5. Check metadata and attachments before treating the review as complete.