The comparison doesn't just check each line against the line in the same position — it looks for the longest run of lines that appear in both texts, in the same order, and treats everything else as added or removed around that shared backbone. It's the same family of algorithm behind git diff and the Unix diff command. Here's a small before-and-after showing it in action:
| Line | Result |
|---|---|
| Team meeting notes | unchanged |
| Discussed Q3 budget | removed |
| Discussed Q3 budget and hiring plan | added |
| Action items due Friday | unchanged |
| Next meeting: TBD | removed |
Only one line actually had new words added to it ("and hiring plan"), and one line was deleted outright — but because the comparison works line by line, the edited line shows as a full removal-and-add pair rather than a small in-line insertion.
Comparing whole lines instead of individual words is what makes this fast and predictable on any size of text, and it's the right unit of comparison for code, configuration files, and CSV rows, where a line is usually one complete unit of meaning. The tradeoff shows up most in prose: change a single word in the middle of a long paragraph-as-one-line, and the entire line reads as "removed" in red immediately followed by the same line "added" in green, which can look like a bigger edit than it really was. For that kind of editing, it helps to break long paragraphs into shorter lines (one sentence per line, for example) before comparing — smaller lines mean smaller, more precise diffs.
It compares your two texts line by line and finds the longest matching sequence, so it can show exactly which lines were added, removed, or stayed the same.
No — comparison happens at the line level. If a single word changes, the entire line will show as removed and re-added rather than highlighting just that word.
Yes — lines that differ only by spacing will be flagged as different, since the comparison is exact.