Diff Checker

Compares two text inputs and highlights line-level differences. The algorithm is a longest-common-subsequence (LCS) variant similar to GNU diff, marking added, removed, and unchanged lines.

Word-level highlighting within changed lines uses a secondary diff pass on whitespace-tokenized text. Output is rendered side-by-side or unified, mirroring the standard diff display modes.

The core algorithm is Eugene Myers' 1986 LCS diff, the same routine that powers GNU diff, git diff, and most code review tools. Its complexity is O(ND) where N is the total number of lines and D is the size of the minimal edit script. In practice this means small changes to large files are nearly free; large changes to small files run in linear time; large changes to large files (rewriting most of a 10,000-line file) approach quadratic worst case but rarely hit it. The output is a sequence of insert, delete, and equal operations that the renderer paints with green, red, and unchanged backgrounds respectively.

A worked example: comparing 'The quick brown fox' with 'The slow brown fox' produces one unchanged line at the line level (the strings differ within a single line, so LCS at line granularity sees a delete + insert pair). The word-level second pass tokenizes each side, runs LCS again on the word arrays, and marks 'quick' as removed and 'slow' as inserted while showing 'The', 'brown', and 'fox' as unchanged. Side-by-side rendering shows the two versions in parallel columns; unified rendering shows context lines plus the change inline with - and + prefixes, the format used by patch files.

Limitations are practical. The algorithm is line-oriented; reordered blocks of code show as one giant deletion and one giant insertion rather than as a move, which is a known weakness of basic diff and is why git later added the -M (move detection) flag for renamed files. Whitespace-only changes (trailing spaces, line ending styles) appear as full-line differences unless normalization is enabled. Binary files cannot be meaningfully diffed at line level; for those, a hex viewer or a binary-aware tool like vbindiff is appropriate. Catastrophic regression on very long lines (a single 100KB line of minified JSON) can stall the word-level diff, since LCS on token arrays of that size approaches the quadratic bound.

Three-way merge (showing how two divergent edits relate to a common ancestor) is a related but distinct operation, not handled here. For that, git's three-way merge driver, KDiff3, or Beyond Compare are appropriate.