Diff Checker

Underneath the highlighting, a diff tool is solving a specific matching problem: given two lists of lines, find the longest sequence of lines that appears, in the same relative order, in both documents — everything in that shared sequence is left unchanged, and everything else is what gets marked as added or removed. This is the intuition behind the "longest common subsequence" idea that every general-purpose diff algorithm is built around, including the one Git itself uses. It explains a detail that otherwise looks odd: moving a block of text from the bottom of a document to the top is usually reported as a large removal plus a large addition, rather than as a single "moved" operation — the algorithm is only looking for a shared order, and a relocated block breaks that order at both its old and new position.

It also explains why a single-character edit to a long line marks the *whole line* as changed in line mode: the algorithm compares whole lines as indivisible units, so "the same line except for one letter" and "a completely different line" are treated identically — both fail the equality check and both count as one line removed, one line added. That is exactly the situation where switching to word mode helps, since it re-runs the same underlying idea one level down, treating each word as the unit being matched instead of each line.

Line mode is the right default for anything where a line is a meaningful unit on its own — source code, JSON objects, CSV rows, log entries — because in those formats a single line usually represents one complete idea, and knowing that a particular line changed is itself useful information, independent of which character within it moved. Word mode becomes more useful the moment the meaningful unit is smaller than a line: a paragraph of prose, a contract clause, or a sentence in a long document, where the interesting change is usually a single word or phrase and the surrounding sentence is identical. Comparing such text line-by-line would mark the entire paragraph as "changed" for a one-word edit, which is technically correct but tells you nothing about what actually changed until you read the whole paragraph again yourself.

A practical rule: reach for line mode first for anything structured or line-oriented, and switch to word mode specifically when a line-mode result shows two large blocks of red and green that look almost identical — that pattern is the signal that the real difference is small and buried inside otherwise-unchanged text.

Comparing two revisions of source code before merging them is the textbook use case, but the same technique applies well beyond a code review: comparing two exports of a configuration file to spot exactly which setting changed between a working deployment and a broken one, checking two versions of a CSV export to confirm only the rows you expected were touched, or comparing a contract draft against a previous revision to find every clause a counterparty modified without reading the entire document side by side again. In every one of these cases the value of a diff tool is the same — it turns "are these two things different, and if so, where" from a manual side-by-side reading exercise into an immediate visual answer.