What this text diff actually compares
Paste two versions of anything into the two boxes and this text diff tool shows you what moved between them: lines only on the left are marked as removed, lines only on the right as added, and lines that survived as a rewrite of one another get a second pass that highlights the words that changed inside them. The unified output at the bottom uses the same three prefixes a patch file does, so you can copy it straight into a review comment.
There are two options, and both exist because of the same problem — a difference that is real to a
string comparison but not to a reader. Ignoring case makes Total and total the same line.
Ignoring leading and trailing spaces makes a re-indented line the same line. Neither option touches
the text you get back; they change only what counts as a match.
Longest common subsequence, and why the answer is not unique
Every line-based diff is answering one question — what is the longest ordered set of lines present in both texts, not necessarily next to each other? That set is the longest common subsequence, and everything outside it is the change. The algorithm here is Myers', the same one Git runs by default, which finds it by walking the shortest path through an edit graph rather than filling a table the size of one text times the other.
The consequence worth knowing is that the answer is often not unique. When a paragraph is duplicated or a closing brace is deleted, there are several equally short edit scripts, and different tools pick different ones. A diff that looks wrong is usually a diff that picked another correct answer.
Where line diffs fall apart
Reflowed prose. If a document is stored with hard line breaks and someone changes the width of the column, every line after the edit shifts along, and a line diff reports the whole rest of the document as rewritten even though a single word changed. Nothing is broken; the tool is answering the question it was asked, and the question was about lines.
Three ways out, depending on what you control. Store prose one sentence per line, which makes the
line a meaningful unit again and is what technical writing repositories do. Turn off wrapping in
your editor before you compare. Or ask for a word diff directly: git diff --word-diff re-runs the
comparison on words inside each changed region, and --word-diff-regex lets you say what a word is
— useful for LaTeX or for a language where punctuation should split.
Word level, not character level
The refinement pass here stops at words on purpose. Character-level highlighting looks precise and reads badly on prose, because it marks the one letter that changed in the middle of a word and leaves your eye to reconstruct which word that was. It also fires on lines that merely happen to share letters, so the pass runs only when the two lines have at least half their words in common — below that they are not a rewrite of each other, and the highlight is dropped rather than guessed.
Need to normalise before comparing rather than after? Remove duplicate lines strips repeats that would otherwise show up as spurious moves, and the regex tester is the faster route when what you want is not the difference between two texts but every place one pattern occurs in one of them.