Why comparing PDFs is harder than comparing Word files
A Word document carries its structure with it: paragraphs, headings, tracked changes. A PDF carries none of that. It is a list of characters placed at coordinates on a page. Two PDFs of the same contract can differ in font embedding, line breaks and page breaks while containing identical text, and a one-word insertion on page two can push every later line, and every later page, out of position.
Any comparison method that works page by page or line by line will therefore report hundreds of differences after a single edit. The useful question is not "which pixels changed" but "which words changed", and answering it needs the text to be extracted, aligned and then compared.
Method 1: read them side by side
This is what most teams still do for anything under twenty pages. It is also how changed numbers get missed. Human reviewers reliably catch a rewritten clause and reliably miss a "30" that became "45" in the middle of an otherwise identical paragraph. Use it only for a final sanity check of a machine-generated redline, never as the primary method.
Method 2: visual overlay in a PDF viewer
Acrobat and several viewers can overlay two PDFs and highlight pixels that differ. This works well for drawings and for detecting whether a page was replaced at all. It works badly for text documents, because reflow after any insertion makes every subsequent page light up. You get a signal that something changed, not a list of what changed.
Method 3: extract the text and diff it
Copying the text out of both PDFs into a diff tool is a real improvement: it compares words, not pixels. The problems are practical. Running headers and footers appear on every page and diff against each other. Page numbers differ on every page. Tables come out in unpredictable cell order. Two-column layouts extract in the wrong reading order. The result is a diff that is technically correct and full of noise.
Method 4: a content-aligned PDF comparison engine
A purpose-built engine does what a careful person would do with unlimited patience. It extracts text with position and style, recognises and removes repeating headers, footers and page numbers, identifies tables that are unchanged and holds them out, reads columns in the correct order, aligns paragraphs between the two documents, and only then compares character by character. The output is a short list of real changes, each with a page number and the old and new text, plus a redlined PDF and a side-by-side view.
This is the method behind the comparison tool on this site. Upload the older and the newer PDF, choose side-by-side or redline, and the result appears in a few seconds. Documents up to 30 pages need no account.
What to check in any comparison result
- Every number, date and defined term in a changed sentence, not only the sentence.
- Deleted text, which is easier to miss than inserted text because there is nothing new to draw the eye.
- Moved paragraphs, which a naive diff reports as a deletion in one place and an insertion in another.
- The last page and any annexes, where changes are often made and rarely reviewed.
Automating it
If you compare documents every week, the web tool is a stopgap. The same engine is available as a REST API: send two PDFs, receive the change list as JSON with page numbers, the redlined PDF and the side-by-side HTML. See the API documentation for examples in curl, Python and Node.
Try it on your own documents. Upload two versions on the homepage. Documents up to 30 pages need no account, and nothing is stored.