Text Diff Checker

At its core, a diff is the answer to a single question: what is the shortest sequence of insertions and deletions that transforms one sequence into another? For text, the sequence elements are usually lines or words. The classic approach is the longest common subsequence (LCS) algorithm — find the longest subsequence that appears in both texts in the same order, then everything not in that subsequence is either an addition or a deletion.

LCS works by building a dynamic programming table where each cell represents the LCS length of the two prefixes up to that point. The algorithm runs in O(n*m) time and space, which is fine for short documents but becomes expensive for large files. In practice, most real-world diff tools add heuristics: they first identify unchanged regions to anchor the diff, then run LCS only on the regions between anchors, dramatically reducing the problem size.

The Myers diff algorithm, published by Eugene Myers in 1986, is the algorithm behind Git's default diff. Instead of finding the longest common subsequence, it reframes the problem as finding the shortest edit script — the minimum number of deletions and insertions needed to transform one sequence into another. Myers showed this is equivalent to finding the furthest-reaching path through an edit graph, and he gave an algorithm that does it in O((n+m)*d) time where d is the edit distance.

The key insight is that the algorithm processes the diff in a greedy, diagonal-first manner: it tries to move diagonally (matching characters) as far as possible, then makes the minimum number of horizontal or vertical steps (insertions or deletions) to reach the next diagonal run. This produces diffs that look natural to humans because it maximizes the amount of matched context before reporting a change. The O(ND) complexity means it's fast for typical files where the edit distance is small relative to file size, but can degrade when comparing two completely different documents.

Line-level diffing treats each line as an atomic unit — a single character change within a line shows the entire line as deleted and re-added. This is the right default for code and configuration files, where lines have independent meaning and a whole-line change is usually intentional. It produces compact, readable diffs that map cleanly to the mental model of 'which lines changed?'

Word-level (or character-level) diffing splits each line into smaller tokens — words or characters — and runs the diff algorithm on those. This reveals that a line change was actually a single word edit, which is much more useful for prose, documentation, or any text where lines are long and edits are localized. The trade-off is visual noise: a word-level diff can highlight changes inside a sentence that a line-level diff would show as a whole-line replacement, making the diff harder to scan quickly. The best approach depends on what you're comparing — use line-level for code, word-level for prose.

A unified diff represents changes as hunks — contiguous blocks of changed lines with a few lines of context on each side. Each hunk header like @@ -1,7 +1,7 @@ tells you the starting line and length in the old and new versions. Lines prefixed with a minus were removed; lines prefixed with a plus were added; unmarked lines are context. Learning to read this format lets you understand any diff tool's output, from Git to patch files to code review interfaces.

One subtle but important point: a diff is not unique. Two different algorithms can produce different (but equally valid) diffs for the same pair of inputs, because there can be multiple minimal edit scripts. This means a diff is a representation of the difference, not the difference itself. When you see a diff that groups changes in an unexpected way, it usually reflects the algorithm's anchoring choices, not an error.

Diffs are the backbone of version control, but they show up everywhere: comparing configuration files before a deploy, reviewing documentation changes, auditing API responses across versions, or even verifying that a refactoring didn't change behavior by diffing the output of a program before and after. Any time you need to know 'what changed between these two versions?', a diff tool is the answer.

For automated workflows, diff output can be piped into scripts. Git's diff with --word-diff=color gives machine-parseable word-level changes. The patch format extends unified diff with enough metadata to reapply the changes to a modified file. For continuous integration, tools that diff API responses between builds can catch unintended breaking changes before they reach production. The diff is one of the oldest and most fundamental tools in computing — understanding how it works makes you better at every kind of text comparison task.