Understanding text diff
What changed between two passages.
Diffing is older than version control. The mathematics underneath is the same now as in 1976.
The longest common subsequence.
Almost every diff algorithm reduces to one core problem: find the longest common subsequence between two sequences of lines. Everything that's in both sides of that subsequence is unchanged. Everything in the original but not in the change is a deletion; everything in the change but not the original is an insertion. The Hunt-McIlroy algorithm from 1976 solved this; modern diff tools use variations on it (Myers's algorithm is the dominant one).
Line-level vs. word-level vs. character-level.
The same algorithm runs at any granularity. Line-level (what this tool shows) is the canonical view — it matches how Git renders changes and how code review tools work. Word-level diffs help when reviewing prose; character-level diffs are useful for spotting typos or invisible Unicode changes. None is "more correct" — they're different resolutions on the same underlying comparison.
Whitespace and the silent surprise.
A trailing space, a tab where there should have been four spaces, a CRLF where there should be an LF — diff tools report these as changes because, byte-for-byte, they are. Most of the time you don't care. Git lets you ignore whitespace in diffs with --ignore-all-space; this tool diffs verbatim, so you can see whitespace changes when they matter (and ignore them visually when they don't).
Why a "best" diff doesn't exist.
For any two non-trivial passages there are many valid sets of edits that transform one into the other. The diff algorithm picks one — usually the one with the fewest inserted-and-deleted lines, but ties happen. That's why the same change can render slightly differently in different tools. The set of changed lines is what matters, not the exact framing.