Spotting the difference between two versions of a document — code, a contract, an essay draft — by eye is unreliable in a specific, well-documented way: when two things look almost identical, your visual system tends to process them as the same thing and gloss over small changes. This is closer to change blindness (missing a difference between two versions of a scene you're actively comparing) than the more commonly cited "inattentional blindness" (missing something unexpected while your attention is elsewhere, like the famous invisible-gorilla experiment) — but the practical result is the same: manual proofreading misses small, deliberate changes surprisingly often.
What a diff algorithm actually does
Most text comparison tools are built on some version of the longest common subsequence (LCS) problem: find the longest sequence of matching lines (or characters) that appears in both texts, in the same order. Whatever isn't part of that common subsequence gets marked as added or removed. Git's diff, and most "diff" tools generally, use a refinement of this called the Myers diff algorithm, which finds a minimal edit path efficiently even on long documents.
This matters practically because of two different levels of comparison:
- Line-level diffing (what
git diffdoes by default) treats each line as a unit. If you reformat one sentence across two lines instead of one, the whole line shows as changed even if only a few words moved. - Character-level diffing compares within a line and highlights the exact characters that changed — useful for catching something like a single altered number or word inside an otherwise identical sentence, which line-level diffing would just flag as "line changed" without telling you what changed.
A basic character-level diff, conceptually:
import difflib
original = "The contract expires on March 1, 2026."
revised = "The contract expires on March 15, 2026."
diff = difflib.ndiff(original.split(), revised.split())
print('\n'.join(diff))
# Output shows "1," removed and "15," added — pinpointing the exact change
# rather than just flagging that the sentence differs somehow
difflib (Python's standard library) and Git both implement variants of this same underlying idea — it's not exotic technology, just something manual reading can't replicate reliably.
Where this actually matters
- Code review — comparing a function against its previous version to confirm only the intended lines changed
- Contract review — a single altered date, number, or negated clause ("shall" vs. "shall not") can flip a contract's meaning; character-level diffing catches exactly this kind of change that's easy to skim past
- Draft revisions — confirming that requested edits were made without accidentally removing surrounding content
- Checking for unoriginal content — comparing a submission against a source text line by line
Two things that trip up diff results
Formatting noise. Curly quotes vs. straight quotes, different line-wrap widths, or trailing whitespace will show up as differences even when the actual content is identical. Stripping to plain text before comparing avoids flagging cosmetic changes as substantive ones.
Semantic rewrites. A diff tool compares text, not meaning — a sentence that's been completely reworded but says the same thing will show as a large change even though nothing meaningful shifted. Diffing tells you where text changed; deciding whether the change matters is still a human judgment call.
Practical approach for large documents
For something like a full contract or a long manuscript, comparing the whole thing at once can bury small but important changes in a wall of highlighted text. Breaking it into logical sections — clauses, chapters, function-by-function — makes it easier to actually register each change rather than skimming past it.
Quick option without setting up tooling
If you don't want to run a script for a one-off comparison, ToolSink's Text Compare tool does character-level diffing in the browser and highlights additions/deletions directly — useful for a quick check without installing anything. As with any web tool, if you're comparing something sensitive (an unreleased contract, private code), check the specific tool's stated privacy behavior rather than assuming it's local processing by default.