Blog
What 'Diff' Actually Means: A Plain-English Walk Through Text Comparison
Line-level versus word-level diffing, and practical uses for text comparison well beyond source code.
"Diff" started as Unix shorthand for a specific 1970s command-line program, but the underlying idea is older and simpler than the tooling around it suggests: given two versions of the same text, find the smallest set of insertions and deletions that turns one into the other. That "smallest set" part matters more than it sounds. Two documents that differ by one added sentence could, in theory, be described as "delete everything, then retype everything" — technically accurate, completely useless. A good diff algorithm searches for the edit that changes the least, which is what makes the output actually readable as "here's what changed" rather than "here are two unrelated blocks of text."
Lines are the default unit, for a practical reason
Classic diff tools compare text line by line rather than character by character. Treat each line as a single unit, check which lines from the old version are also present in the new one (and in what order), and the algorithm's job becomes finding the longest matching subsequence of shared lines — everything else gets marked as removed from the old side or added on the new side. This is fast and, for source code especially, produces genuinely useful output, because code is already organized into meaningful line-sized chunks: a function signature, a single statement, an import. The catch is that line-level diffing treats an entire line as either "unchanged" or "different," with nothing in between. Change one word in a 40-word line and the whole line shows up as fully deleted and fully re-added, which can bury a tiny edit inside what looks like a big rewrite.
Word-level diffing fixes the granularity problem
Word-level (or character-level) diffing applies the same longest-common-subsequence idea, but treats individual words as the unit of comparison instead of whole lines. Change "the quarterly report is due Friday" to "the quarterly report is due Monday" and a word-level diff correctly highlights just "Friday" as removed and "Monday" as added, leaving the identical surrounding words unmarked. This is far more useful for prose than line-level diffing, since paragraphs don't have the same tidy one-idea-per-line structure that code does — a single sentence edit sitting inside a long paragraph would otherwise flag the entire paragraph as changed under a pure line-based comparison. Most practical diff tools run both passes: line-level first to figure out which lines correspond to which, then word-level within lines that were matched but not identical, to show exactly which words moved.
Diffing isn't just for code
Version control gets the most attention, but text comparison shows up anywhere two versions of a document need to be reconciled. Contract redlines are a diff problem: a lawyer needs to see precisely which clauses a counterparty edited, not re-read the entire agreement hoping to spot the change by eye. Editing a manuscript through several drafts is a diff problem — did the revised chapter actually address the note about pacing, or did the author just rephrase the same paragraph? Comparing two exports of a configuration file, two versions of a company policy document, or even two paste-ins of the same email thread to spot what got edited before forwarding are all the same underlying task: find the minimal, human-readable description of what changed between two blocks of text.
What a diff can't tell you
A diff shows what changed, not why, and it has no concept of whether a change is meaningful. It will flag a single trailing space as a difference with the same visual weight as a rewritten sentence, which is why tools often offer an option to ignore whitespace-only differences. Reordering two paragraphs, meanwhile, typically shows up as a full delete of both paragraphs from their old positions and a full re-add at their new ones — a diff algorithm is comparing positions in a sequence, not tracking "this same block of text moved," so a reorder reads as much noisier than what actually happened conceptually. Knowing this limitation is useful: when a diff between two drafts looks like an enormous rewrite, it's worth checking whether a paragraph just got moved before assuming the content itself changed that much. TheDiff Checker on this site runs both line and word level comparison so you can switch between "what lines changed" and "what exactly changed within them" depending on which question you're actually asking.
