Every diff tool promises to show what changed. The algorithm underneath decides how small the change looks, how fast the tab responds, and what a rewritten line costs you. Git ships the Myers algorithm. Our text diff checker ships the classic longest common subsequence dynamic program. Here is both, from our own code.
The LCS Pipeline in Our Diff Checker
1. Split both texts on newline into two arrays of lines.
2. Allocate a table of (m plus 1) by (n plus 1) cells, where m and n are the line counts. Fill it backwards so each cell stores the length of the longest common subsequence of the lines remaining from that point.
3. Walk the table from the top. Matching lines emit as unchanged. On a mismatch, compare the two candidate next cells, and when they tie the walk emits the added line before the deleted one.
4. Count the adds and deletions for the chips above the inputs.
Line equality is exact string comparison. A trailing space, a changed tab, or a different line ending makes two otherwise identical lines count as different. There is no option to ignore whitespace or case, because the comparison step has no such branch.
What LCS Costs at Scale
The table is the whole cost model. Two inputs of 1,000 lines each allocate 1001 by 1001, about 1,002,001 cells. Two inputs of 5,000 lines allocate 5001 by 5001, about 25,010,001 cells. Two inputs of 10,000 lines allocate 10001 by 10001, about 100,020,001 cells.
Time and memory both grow with the product of the line counts, regardless of how much actually changed. A pair of 10,000 line files with three edited lines still pays for the full hundred million cell table. That is the failure mode, a tab that freezes on large inputs even though the difference is tiny.
How Myers Diff Does It Differently
Git's default diff runs the Myers algorithm. Its cost tracks the edit distance, meaning the number of insertions and deletions, plus the input length. The same pair of 10,000 line files with three edits is cheap work for Myers, because the algorithm hunts down the diagonal path through the few changes and never builds a quadratic table.
Both algorithms produce a minimal edit script, so neither shows extra changes. The difference is what you pay, not what you see. The one visible difference is tie-breaking, which minimal script you get when several are equally short. Our walk prefers the added line first on ties, a rule you can verify by diffing two texts where a line moved.
Line Level Behavior You Will Notice
- A modified line appears twice, once in red as a deletion and once in green as an addition, and both count in the chips. A rewrite of 10 lines shows plus 10 and minus 10, so read the two numbers together rather than as a change count.
- The Copy Patch button produces lines prefixed with plus, minus, or two spaces. The output has no hunk headers and no file headers, so git apply will not accept it. Use it in commit messages, review notes, and emails, not as an appliable patch.
- The numbers down the result panel number output rows, not lines in either input. A deletion and its replacement addition share consecutive row numbers.
- Both boxes open with a preloaded sample. Press Clear on each pane before pasting real content.
- The comparison is whole-line. There is no word-level or character-level highlighting inside a changed line.
When to Use Which
1. If both inputs fit comfortably on screen, a few hundred lines, use the browser checker. The table is trivial at that size and nothing leaves your machine.
2. If you need to prove what changed in a contract, a policy, or a returned draft, paste both versions and read the red and green lines. The minimal edit script guarantees no change hides.
3. If either input exceeds about 5,000 lines, switch to git diff or your platform's native compare. The quadratic table is the bottleneck, not your patience.
4. If you need an appliable patch, generate it with git diff, because our copy format is for humans.
Checklist
- [ ] You cleared both sample panes before pasting.
- [ ] You remembered that one modified line shows as one deletion plus one addition.
- [ ] You treated row numbers as output positions, not source line numbers.
- [ ] You did not try to git apply the copied patch.
- [ ] You moved large comparisons to git diff before the tab stalled.
Compare two versions of any document on the [text diff checker](/en/text-diff) and watch where a moved line lands. If your moved line produced a different pairing than the add-first rule predicts, send us both texts, because that would mean our walk rule description needs a correction.
