Comparing "before" and "after" versions of a piece of text — a contract redline, a code diff, a tracked-changes document — feels like it should have one obviously correct way to highlight what changed. In practice, diff algorithms have to make judgment calls that occasionally produce a technically accurate but visually confusing result, and understanding why reveals something genuinely interesting about how difficult "what changed" actually is to define precisely.
The core problem: many different valid ways to explain the same change
Given an original text and a revised text, there are typically many different, equally valid ways to describe the transformation between them as a sequence of additions and deletions. If a sentence gets reordered, a diff algorithm could describe that as "delete the whole sentence, then add it back in the new position," or it could potentially describe smaller portions of the sentence as unchanged text that simply moved, depending on how much of the surrounding context happens to overlap. Both descriptions are technically accurate representations of the same underlying change, but they produce very different-looking diff output, and a diff algorithm has to pick one representation to actually display.
Most diff tools optimize for the "shortest edit script"
The most common approach used by diff algorithms is finding what's called the shortest edit script — the smallest possible number of additions and deletions that transforms the original text into the revised text. This is a genuinely sensible default goal, since a shorter, more minimal set of changes is usually easier for a human to read and understand than a longer, more convoluted explanation of the same transformation. But "shortest" doesn't always mean "most intuitive to a human reader" — a technically minimal edit script can sometimes describe a change in a way that doesn't match how a person would naturally describe what actually happened, particularly around reordered or moved content.
Why moving a block of text often looks like delete-and-add rather than "moved"
Most standard diff algorithms don't have a specific, dedicated concept of "this content moved from one location to another" — they only understand additions and deletions as the two available operations. When a paragraph genuinely moves from the beginning of a document to the end, a standard diff typically represents that as a deletion at the original location and an addition at the new location, even though a human reviewer looking at both versions would naturally describe it as "this paragraph moved," not as two conceptually unrelated add-and-delete operations that happen to contain identical text. Some more specialized diff tools do include explicit move-detection as an additional feature, but it's not part of the basic diff algorithm most tools are built around by default.
Word-level versus line-level versus character-level granularity changes everything
A diff algorithm needs to decide at what granularity it's comparing the two texts — treating each entire line as the smallest indivisible unit of comparison, treating each individual word as the smallest unit, or going all the way down to individual characters. A single-word change in the middle of an otherwise-identical long line will show as the entire line being deleted and re-added if the diff is operating at line-level granularity, even though only one word actually changed — which is exactly why a line-level diff can look far more dramatic and harder to parse than a word-level diff of the exact same underlying edit, despite both being technically accurate representations of the identical change.
Why this matters for choosing the right diff granularity for your task
Because the same underlying change can be represented very differently depending on the comparison granularity chosen, picking the right level of detail for a specific task genuinely matters for how useful and readable the resulting diff actually is. Reviewing changes to source code typically benefits from line-level diffs, since code structure is naturally organized around lines and a line-level change usually maps cleanly onto a logical unit of code. Reviewing edits to prose writing — a contract, an essay, a marketing copy revision — usually benefits far more from word-level diffing, since prose edits are frequently small word-level substitutions within an otherwise-unchanged sentence, which a line-level diff would misleadingly represent as the entire surrounding sentence or paragraph being replaced.
Comparing your own text
Our word-level text diff tool is specifically built for comparing prose-style edits at the word level rather than the line level, precisely for the reason described above — it avoids the misleadingly dramatic whole-line-replacement representation that a line-level diff would produce for what's often just a small, targeted word-level change within an otherwise identical sentence.