About this tool
The Text Diff Tool compares two blocks of text line by line and highlights additions (green) and deletions (red). Useful for comparing code changes, document revisions, or configuration file differences. All processing is local - no data leaves your browser.
About text diffing
A text diff compares two versions of the same content and shows what changed. It is the workhorse of every code review, every Wikipedia history page, every Word "track changes" view, and every Git pull request on the planet. The output is an edit script: a minimal list of insertions and deletions that transforms version A into version B. Most readable tools, including this one, render that script side by side or inline, with additions in green and deletions in red.
This page runs a line-level diff in your browser. There are three families of diff: character, word, and line. Character diff is exhaustive and noisy. Word diff is good for prose. Line diff is the default for code and config because programming languages use newlines as statement boundaries, so a line-level edit script lines up cleanly with semantic units like statements and configuration entries.
How the algorithm works
The tool implements the classic Longest Common Subsequence (LCS) diff popularised by Hunt and McIlroy in 1976 and still the basis of GNU diff, Git, and Mercurial. The process has three stages.
1. Split A and B into line arrays
2. Build an LCS matrix L[i][j] of size (|A|+1) x (|B|+1)
L[i][j] = L[i-1][j-1] + 1 if A[i-1] == B[j-1]
= max(L[i-1][j], L[i][j-1]) otherwise
3. Backtrack from L[|A|][|B|] to recover the edit script
- Lines on both diagonals of the matrix are kept (unchanged).
- Lines that fall off horizontally are insertions from B.
- Lines that fall off vertically are deletions from A.
- Time and space complexity are both O(n times m), which is why very large inputs slow down.
Worked example
Compare the default inputs on this page. Side A has four lines, side B has four lines, and they differ on lines 1, 2, and 4.
- Line 1: "The quick brown fox" vs "The quick brown cat". Line diff sees the whole line changed: one deletion plus one addition.
- Line 2: "Hello world." vs "Hello world!" Same line-level treatment: one delete, one add.
- Line 3: identical, kept as unchanged.
- Line 4: "Remove this line." replaced by "Added new line here." One delete, one add.
Diff modes compared
| Mode | Granularity | Best for | Cost |
|---|---|---|---|
| Character diff | Per code point | Single-line tweaks, label edits | Very high noise |
| Word diff | Whitespace tokens | Prose, articles, contracts | Token boundary heuristics |
| Line diff (this tool) | Per newline | Code, config, logs, JSON | O(n times m) memory |
| Patience diff | Per newline, anchor lines first | Reordered code blocks | Slower preprocessing |
| Myers diff | Per newline, shortest edit script | Git default, large files | Linear in edit distance |
Common pitfalls
- Mixed line endings. A block pasted from Windows uses CRLF; macOS or Linux uses LF. The two will never match line for line. Normalise endings before diffing.
- Trailing whitespace. Tabs vs spaces and trailing spaces flip a line from "kept" to "changed". Strip them if your goal is semantic comparison, not formatting audit.
- Reordered blocks. LCS does not understand "this block moved". It will report the original block as deleted and the new position as added. Patience diff handles this better.
- Word-level edits inside a long line. One typo fix shows as a full-line delete plus add. Use a word diff for prose work.
- Big files. Memory grows quadratically. Diffing two 50,000-line files allocates roughly 2.5 billion matrix cells. Use git diff or diff -u for that.
- Sensitive content. Even though this tool is local, your clipboard manager might have logged the paste. Clear it after diffing secrets.
Related tools
Frequently asked questions
What algorithm does this text diff use?
The tool runs a Longest Common Subsequence (LCS) line diff entirely in your browser. It builds an LCS matrix from the two input arrays, walks back to recover the edit script, and tags each line as kept, added, or deleted. LCS is the same family of algorithm Git uses under the hood for its default diff output.
Does this tool send my text to any server?
No. The diff runs entirely in JavaScript on your device. Nothing leaves the page. You can confirm this by opening DevTools, switching to the Network tab, and clicking Compare: no XHR or fetch fires. This makes the tool safe for pasting in code snippets, draft contracts, log files, or anything you do not want logged externally.
Why does my diff show extra additions and deletions instead of a clean change?
Line diff treats each line as atomic. If you edit one word inside a line, the whole line shows as one deletion plus one addition. That is a property of line-level LCS, not a bug. For word-level or character-level diffs you need a different algorithm, which this tool does not run.
Does this handle trailing whitespace and line endings?
The tool splits on the literal newline character and does not normalise trailing spaces or CRLF vs LF. A line ending in CR before LF will not match the same line in LF only. If you are getting mystery deletions, paste both blocks into a plain text editor first to normalise endings, then re-run the compare.
What is the maximum size of text I can compare?
LCS runs in O(n times m) time and memory. A few thousand lines on each side is fine on a modern laptop. Tens of thousands of lines will lock the tab briefly because the matrix grows quadratically. For very large files use a CLI tool such as git diff, diff -u, or delta.