How a Diff Tool Decides What Actually Changed

The problem is more subtle than it sounds

Comparing two versions of a document sounds simple, but a diff tool has to solve a genuinely ambiguous problem: given two sequences of lines, what's the smallest, most sensible set of additions and removals that turns one into the other? There's often more than one technically valid answer, and a bad choice makes a diff far harder to read than it needs to be.

The longest common subsequence approach

The standard solution, used by classic Unix diff and by Git, is to find the longest common subsequence — the longest run of lines that appears in both texts in the same relative order, even if other lines are interspersed. Everything in that shared subsequence is treated as unchanged; everything else is marked as removed from the original or added in the new version. This naturally keeps unrelated matching lines aligned as context, instead of naively comparing line 1 to line 1, line 2 to line 2, and so on, which falls apart the moment a single line is inserted near the top.

Why a single edited line shows as two changes

If you change one word in a long line, a line-level diff can't know that — it only compares whole lines, so an edited line is reported as the old line removed and the new line added, not as a partial edit. This is a real, well-known limitation of line-based diffing, and it's why some tools additionally offer word-level or character-level diffing for finer-grained comparisons.

Try it yourself

Our Text Diff Checker uses this same longest-common-subsequence approach to compare two texts line by line, entirely in your browser.