Someone returns a contract "with a few small changes". The comparison tool reports that 38 of 40 pages differ. Two of those pages contain a real edit and the other 36 moved down by four lines.
Which comparison you are running decides whether that happens.
Three different questions
Text comparison extracts the words from both files and finds the minimal set of insertions and deletions that turns one into the other. It answers: what words changed?
Visual comparison renders both to images and highlights regions where the pixels differ. It answers: where does this look different?
Structural comparison, which is what Word's own compare does, works on the document model, so it can distinguish a changed paragraph from a moved one and can report formatting changes separately from text changes.
They give different answers to the same pair of files, and none of them is wrong.
The reflow problem
This is the single biggest source of noise, and it is worth understanding because it is not a defect.
Insert a sentence on page 2 of a 40-page document. Every subsequent line moves. A visual comparison correctly reports that nearly every page now differs, because nearly every page does differ in pixel terms.
A text comparison handles it correctly, because it compares sequences of words and is indifferent to where they landed on a page. This is the underlying mechanism described in how diff tools find changes: the algorithm looks for the longest common subsequence, so shifted-but-unchanged content is recognised as unchanged.
So the rule is: if both files contain real text, compare the text. Fall back to visual only when one of them is a scan.
Granularity changes what you see
A line-based comparison reports an entire line as changed when one word in it changed, which is right for code and unhelpful for prose, where a paragraph is one long line.
A word-based comparison is what you want for documents. It shows the three words that actually changed inside a paragraph rather than flagging the paragraph.
The diff checker highlights the changed words inside each changed line, which is most of the difference between a readable result and a wall of red.
Clean before you compare
Most false positives are formatting, not content.
Smart quotes are a specific and common culprit. A document that has been through Word has curly quotes; one that has been through a plain editor has straight ones. Every quoted phrase then reports as changed.
The same applies to line endings, which differ between Windows and Unix systems and are invisible. A file that appears entirely rewritten, with no change you can see, is usually this.
Documents and PDFs
For two Word files, document comparison works on the text and reports insertions and deletions in place. This is also what Word's own Compare feature does, and it produces a marked-up document you can walk through and accept or reject.
For two PDFs, PDF comparison picks its approach based on what is in them. If both have a text layer, the comparison is textual and precise. If either is a scan, it falls back to visual and inherits the reflow problem described above.
Which means the most useful thing you can do for future comparisons is run OCR on scanned documents when you file them, rather than when you need to compare them. A text layer added at filing time makes every later comparison precise instead of approximate.
When the answer is not a diff
If you control both versions and the document matters, the comparison problem is a symptom rather than the issue. A DOCX cannot be diffed meaningfully because it is compressed XML, which is the argument in writing in Markdown and generating the Word file later: a plain-text source gives you a real change history instead of a reconstruction.
That does not help with a contract someone else drafted, which is exactly when you need comparison most. For that case:
- Get both as text if you can, rather than as scans.
- Normalise whitespace and quotes on both sides.
- Compare at word granularity.
- Read the seams, meaning the areas immediately around each reported change, because that is where a subtle edit hides next to an obvious one.