Comparing two versions of a document by reading them side by side works for a paragraph and fails for a page. A diff does it properly, and understanding how it decides what changed explains the cases where its output looks bizarre.
Diffs find the longest thing in common
The standard approach solves a problem called the longest common subsequence: what is the longest sequence of lines appearing in both versions, in the same order, allowing gaps? Everything in that sequence is unchanged. Everything else is an insertion or a deletion.
Notice what is missing from that description: there is no concept of a line being "modified". A changed line is a deletion plus an insertion. Tools display the pair together to be helpful, which is why a small edit can appear as one whole line removed and another added.
Why a moved block looks like a rewrite
Because the common sequence must appear in the same order in both versions, moving a paragraph from the top of a document to the bottom cannot be described as a move. It becomes a deletion in one place and an insertion in another, even though not a word changed.
Some tools detect moved blocks as a separate feature layered on top. If yours does not, a reorganised document will show far more change than actually occurred.
Line endings: the invisible difference
This is the single most common cause of a diff that says everything changed when nothing did. Windows ends lines with carriage return plus line feed; macOS and Linux use line feed alone. The characters are invisible, but to a diff they are part of every line.
Open a file on Windows, save it, and every single line may now differ. The fix is to normalise line endings before comparing, or use a tool that ignores them. Trailing whitespace causes the same confusion for the same reason: invisible on screen, significant to the comparison.
Line diff versus word diff
A line diff treats each line as one unit. Change a comma and the whole line is marked. That is right for code, where a line is a meaningful unit, and unhelpful for prose, where a paragraph may be one very long line and a single correction lights up the entire thing.
A word-level diff highlights only the changed words within a line, which is what you want for contracts and articles. If a prose comparison looks useless, check whether you are looking at a line diff.
Reading a diff well
- Scan for large blocks first, which are usually structural moves rather than genuine edits.
- If everything is marked, suspect line endings or trailing whitespace before assuming a real rewrite.
- For prose, switch to word-level highlighting.
- Remember that a "modified" line is a delete and an add displayed together, so reading them as a pair is what shows the actual change.
Where it is genuinely useful
Contract revisions where the other side says "minor changes". Configuration files that worked yesterday. Two exports that should be identical and are not. Checking what an editor actually altered in your draft. In each case the value is the same: certainty about what changed, instead of a reading of what someone says changed.