How to compare two texts and actually see what changed
Someone returns a contract "with a few small edits". Reading both versions side by side to find them is a bad use of an afternoon, and human eyes are unreliable at it — we skim, and a changed number reads the same as an unchanged one.
What a diff actually computes
A diff does not compare the texts line by line in the obvious way. It solves a specific problem: find the longest common subsequence — the largest set of lines appearing in both versions, in the same order, not necessarily adjacent. Everything outside that set is then labelled added or removed.
This is the same approach behind the Unix diff
command and Git. It matters because it explains the behaviour people find surprising: a diff
has no idea what a sentence means. It is matching sequences.
Why a one-word edit lights up the whole paragraph
The commonest complaint about diffs, and it follows directly from the above. If the text is stored as one line per paragraph, then the unit being compared is the paragraph. Change one word and the whole paragraph no longer matches, so it is marked removed and its replacement marked added.
Nothing is broken — the granularity is just wrong for what you are reading. Two fixes: put each sentence on its own line before comparing, which makes the changed sentence stand out instead of the paragraph, or use a word-level comparison if the tool offers one. For prose, sentence-per-line is usually the more readable of the two.
The invisible differences
When two texts look identical but the diff insists they are not, it is almost always one of four things, none of which you can see:
- Trailing whitespace. A space at the end of a line. Invisible everywhere except a diff.
- Line endings. Windows ends lines with CRLF, macOS and Linux with LF. A file that has crossed platforms can differ on every single line while looking untouched.
- Smart quotes. Word and Google Docs silently replace straight quotes with typographic ones. Paste from a document and you get curly quotes; type the same text into a plain editor and you get straight ones. They are different characters.
- Non-breaking spaces. U+00A0 looks exactly like a normal space and is a different character. Copying from a web page brings them along.
If a comparison is full of differences you cannot see, this is why. It is also a genuinely useful signal in a contract: an em dash quietly becoming a hyphen is nothing, but a non-breaking space appearing inside a figure can mean the figure was retyped.
Where this is worth doing
- Returned contracts. The one case where missing a change is expensive. Compare before signing, not after.
- Config files. Working versus broken. The diff is usually one line, and finding it by reading is thankless.
- Draft revisions. Especially when several people edited without tracked changes.
- Anything pasted twice. Two exports that should be identical, from different runs or different environments.
A note on what you are pasting
Contract drafts, internal documents and configuration files are exactly the material people drop into online comparison tools without thinking, and a config file often contains credentials. Worth knowing whether the tool sends it anywhere — the network-tab test answers that for any site in about thirty seconds. Ours does the comparison in the page; nothing you paste is transmitted.