Text Diff Checker
Paste two versions of text to see what changed. Differences are highlighted side by side.
Updated July 11, 2026
100% Private & Secure
This tool runs in your browser.
Your data is never uploaded or stored.
How to use
- 1
Paste the original text on the left.
- 2
Paste the modified text on the right.
- 3
See highlighted differences.
When to use it
Reviewing a config or contract change
Paste the old and new versions of a JSON config, YAML manifest, or legal clause. Side-by-side highlighting shows exactly which lines were added, removed, or changed, so you can approve the change with confidence.
Catching accidental edits in copied text
When two copies of a contract, README, or policy file should be identical but you suspect drift, a diff pinpoints the differing lines in seconds — far faster than reading both end to end.
Comparing translation or rewrite drafts
A diff between a manual rewrite and the original shows which sentences were left intact versus rephrased, which is useful when editing translations or tightening prose without losing meaning.
Verifying cleanup scripts
Run a formatter, minifier, or find-and-replace and diff the output against the source. A clean diff confirms the script touched only what it was supposed to.
How it works
The longest common subsequence, in plain terms
Most text diff tools reduce the problem to finding a longest common subsequence (LCS) — the longest sequence of lines that appears in both inputs, in order, though not necessarily consecutively. Once the LCS is known, everything not in it is a deletion from the left input or an addition in the right input.
The classic LCS algorithm, due to Hunt and McIlroy (1976), was the basis of the original Unix diff and is still good enough for many tasks. It builds a match table between the two sequences and traces a path through it to recover the shared lines.
- A subsequence keeps order but skips elements — "ace" is a subsequence of "abcde"
- The LCS is rarely unique — there may be several equally long shared sequences
- Longer LCS means the inputs are more similar, which means a shorter, cleaner diff
Why modern diff is O(ND), not O(N²)
Myers' 1986 paper An O(ND) Difference Algorithm and Its Variations reframed the problem as a shortest-path search on an edit graph. N is the sum of the two sequence lengths; D is the number of edits (the true edit distance).
When the inputs are nearly identical — the common case for successive versions of the same file — D is tiny, so the algorithm runs in near-linear time. This is why git diff feels instant on most commits despite comparing thousands of lines. The worst case (completely different files, large D) degrades to O(N²), and Myers' linear-space variation trades a constant factor for an O(N) memory footprint.
Character diff vs line diff, and word-level trade-offs
A line diff treats each line as an atomic unit: change one character on a 200-character line and the whole line is marked as removed and re-added. This is fast and matches how programmers think, but it overstates changes in prose.
A character diff compares inputs byte-by-byte (or code point by code point) and highlights the exact characters that differ. It is precise but noisy on structured text — a single inserted { can ripple through the whole output. Most UIs compromise with a word-level diff: split on whitespace first, then diff the token lists, which gives readable highlights without the noise of per-character comparison.
Line: "-The quick brown fox" "+The slow brown fox"
Char: "The {quick|slow} brown fox"Common mistakes & edge cases
A tiny edit marks the entire paragraph as changed
You are looking at line-level diff. Reformatting or reflowing text shifts every line break, so each gets flagged. A word- or character-level diff shows the real change.
Line endings cause false positives (CRLF vs LF)
Normalize line endings before diffing — convert both inputs to LF (\n) so the algorithm compares content, not invisible carriage returns.
Trailing whitespace makes "identical" lines look different
Trim trailing spaces on both sides, or run the inputs through a formatter first. Tabs vs spaces cause the same false positives.
Reordering two paragraphs shows as delete-then-add instead of a move
Plain diff has no notion of a "move" — it only sees additions and deletions. Some advanced tools (git's -M and -C flags) detect moves heuristically, but a basic checker will not.