A PDF difference finder — and what "difference" actually means

Three definitions of "difference"

Different tools answer the question "what's different?" in different ways. The choice matters because each answer surfaces a different category of changes — and misses others entirely.

This is what most "free PDF compare" tools do. They extract the text layer from each PDF, run a string diff, and show you the text-level changes. Fast and accurate for clean text documents (contracts, reports). Almost useless for drawings, scans, or anything graphical.

This is what PDFverifier does. Both PDFs are rendered to high-resolution images, and the images are compared pixel by pixel. Catches everything that's visually different — text, graphics, layout, hatching, line weights. Slower than text-diff but works on anything that's actually visible on the page.

A few research-grade tools parse the PDF object structure and diff it. Most thorough but extremely sensitive to how each PDF was produced — two PDFs that look identical can have totally different object structures if exported from different software. Rarely useful in practice.

What counts as a difference in pixel-diff specifically

PDFverifier flags any region of the page where the new rendering differs from the old rendering by more than the sensitivity threshold. Concretely:

• A line moved 5 pixels to the right → flagged as a change in two regions (the original line is now a "deletion", the new position is an "addition")
• A character changed from "1" to "7" → flagged as a change in the pixel region containing that character
• A hatch pattern changed from concrete to insulation → flagged across the entire hatched region
• A revision cloud was added around an existing element → flagged as an addition (the cloud); the element inside isn't re-flagged since it didn't change
• A line width changed from 0.18 to 0.35 mm → flagged as a change along the line
• A paragraph reflowed onto the next page → flagged on both pages (deletion on the old page, addition on the new)

The key insight: pixel-diff doesn't care why things look different. It only cares that they look different. The interpretation is left to you, the human reviewer.

What doesn't count as a difference

PDFverifier doesn't flag things that are intentionally identical despite differing in non-visual ways:

• Same image rendered from a different source. If the same logo is embedded as a JPEG in one PDF and a PNG in the other, but renders to the same pixels — no flag.
• Metadata changes. Different author, different creation date, different software fingerprint — none of this is visible on the page, so none of it is flagged.
• Internal PDF structure changes. Different compression, different font embedding strategy, different object ordering — invisible to the renderer, invisible to the diff.
• Invisible layers. A non-printing CAD layer that exists in the source DWG but isn't rendered in the PDF doesn't exist as far as the diff is concerned.

This is generally what you want. The question being answered is "does the PDF look different?" — and the answer is determined by what's visible.

False positives, and what to do about them

Pixel diff is exact, which means it sometimes flags differences that aren't meaningful. Common sources:

For genuine review work, the practical workflow is: run at the right sensitivity, accept that a few false positives will appear, and dismiss them as you go through the change list. The tool is built around this — every detected change has an explicit accept/reject button.

Why this is useful

Knowing what the tool actually checks helps you trust the result. If you've ever used a comparison tool, gotten "no changes" as the output, and then later discovered an important change you missed — you've experienced the cost of using a tool whose definition of "difference" didn't match yours. Pixel diff matches the human definition of "visually different" closely, which is usually what you want.