Text FIELD NOTES · 4 MIN READ
Line Diff vs Word Diff: Choosing the Right Comparison
Three resolutions for 'what changed': the line diff's changelog, the word diff's editor pencil, and edit distance's single number — and when each is the right tool.
"What changed?" has more than one answer, because it depends what you slice the text into. Slice into lines and a diff reads like an editor's changelog. Slice into words and it reads like an editor's pencil. Measure characters and you get a number instead of a map. The three views — line diff, word diff, and edit distance — answer the same question at three resolutions, and choosing the right one is most of the job.
The line diff: a changelog of lines
A line diff compares two texts as sequences of lines and finds the longest common subsequence (LCS) — the longest set of lines that appear in both texts in the same order, gaps allowed. Everything not in that common spine is a deletion (in the old text only) or an addition (in the new one only):
old: alpha\nbanana\ncherry new: alpha\nblueberry\ncherry
equal alpha (line 1 = line 1)
deleted banana (line 2 of A)
added blueberry (line 2 of B)
equal cherry (line 3 = line 3)
summary: +1 -1 (2 unchanged)
That output shape — each entry typed as equal, deleted, or added and tagged with its line number on each side — is the changelog view. It is the right unit when lines are the meaningful unit: config files, lists of names, log excerpts, code. The Text Diff tool adds two tolerance knobs, ignore-whitespace and ignore-case, so a line that differs only by an indent or a capital can still count as unchanged. One honest subtlety: LCS allows non-adjacent matches, so a moved block usually shows as deleted-here, added-there rather than as a "move" — most diffs, including this one, do not model moves at all.
The word diff: an editor's pencil
For prose, lines are the wrong scalpel — change one word in a paragraph and a line diff condemns the whole line. The word diff runs the same LCS algorithm over words instead of lines, splits only on whitespace, and merges adjacent changes of the same type so the output reads as sentence pieces:
A: the quick brown fox
B: the quick red fox
equal "the quick"
deleted "brown"
added "red"
equal "fox"
words: 4 -> 4, +1 -1, unchanged 3, similarity 75%
The similarity figure is a Dice-style overlap: twice the unchanged words divided by the total word count of both texts, 2 × 3 / 8 = 75%. It answers "how much of this text survived?" rather than "where exactly?", which makes it handy for spotting near-duplicate paragraphs. Scale has a limit: the word diff caps at 4000 words per text — long novels should meet at the Text Diff tool instead, which works line by line and happily eats thousands of lines.
The character yardstick: edit distance
The third view returns a number. Levenshtein edit distance counts the minimum single-character insertions, deletions, and substitutions that turn one string into the other — the classic cost of turning kitten into sitting is 3 (k→s, e→i, plus the trailing g). Normalized against the longer string, that is 3/7, so the Text Similarity Checker reports 42.86% distance and 57.14% similarity, plus an identical flag for the exact-match case. No map of changes comes out — just "how far apart are these two strings", which is the right question for fuzzy matching, typo tolerance, and near-duplicate detection where there is no "where" worth drawing.
Choosing the unit
The decision is about the size of a meaningful change in your text. For structured text — configs, lists, logs, code — a line is the natural unit of intent, so take the line diff. For prose, where a one-word edit is meaningful and a reflowed line is not, take the word diff. When you do not need a map at all, just a verdict — are these two strings plausibly the same thing? — take the similarity number. A useful companion distinction: a hash tells you whether two texts differ in one bit, as described in How Hashing Works, while a diff tells you where — you hash to detect, you diff to explain.
Reading the output honestly
Diff output invites over-reading. A "changed" line is really a deletion next to an addition — the tool never claims the pairing, the reader does, and the pairing can be wrong. The unchanged count is the load-bearing number: it is what both texts share, and the additions and deletions are symmetric bookkeeping around it. And the tolerance knobs change the story: with ignore-case on, Title and title match and the diff shrinks; with them off, the same texts report a change. Before quoting a diff, check which knobs produced it — the summary line +1 -1 is only as truthful as the options above it.
Try it yourself
Take a six-line list, change one entry, and run both versions through the Text Diff tool — first raw, then with ignore-whitespace on, to see the knobs work. Paste the prose versions of the same text into the Word Diff Checker and compare the segment output and the similarity percentage. Finally, feed two near-miss strings like kitten and sitting to the Text Similarity Checker and watch edit distance condense the whole comparison into one number.