Text Diff Checker
Paste your original and modified text, then click Compare to see what changed. Added lines are highlighted green, removed lines red, unchanged lines grey. Runs entirely in your browser — nothing is uploaded.
Enter text in both fields and click Compare.
How to use the text diff tool
- Paste your original text in the left box and the modified text in the right box.
- Optionally check Ignore leading/trailing whitespace if you only care about content changes, not indentation.
- Click Compare. The diff appears below: green lines were added, red lines were removed, unmarked lines are unchanged.
What is a text diff?
A "diff" (short for difference) shows the minimum set of changes needed to turn one version of a text into another. Diffs are used in version control (git, SVN), code review, document comparison (contract versions, article revisions) and data validation (comparing exported CSV files, config files).
The algorithm used here is LCS (Longest Common Subsequence) — it finds the
longest sequence of lines common to both texts, then marks everything else as added or
removed. This is the same algorithm that powers diff(1), git diff
and most code-review diff views.
From Hunt and McIlroy to Myers: a short history of diff
The diff utility was written at Bell Labs and shipped with Unix in the
mid-1970s. Its algorithm was published in June 1976 by James W. Hunt and M. Douglas McIlroy
as the Bell Labs Computing Science Technical Report "An Algorithm for Differential File
Comparison." Hunt built the prototype; McIlroy refined it. It was one of the first
non-heuristic file-comparison tools, and it framed the problem the way every diff tool still
does today: find the longest common subsequence (LCS) of the two files,
then report everything outside that common spine as added or removed.
A decade later, in 1986, Eugene W. Myers published "An O(ND) Difference Algorithm and Its Variations" in the journal Algorithmica. The Myers algorithm is faster and easier to reason about, and it became the default in Git and in countless editors and review tools. The diff you see on this page rests on the same LCS foundation those two papers established.
Diffing as a shortest edit script: the Myers algorithm
Myers reframed comparison as a path-finding problem on an edit graph. Picture the original file laid along the top of a grid and the modified file down the side. A move right deletes a line, a move down inserts a line, and a diagonal move keeps a line that matches in both. The best diff is the path from the top-left corner to the bottom-right that takes the most diagonal steps — equivalently, the one with the fewest inserts and deletes. That minimum number of insert and delete operations is the shortest edit script.
The algorithm runs in O(ND) time and space, where N is the combined length of the two inputs and D is the edit distance — the size of that shortest edit script. The crucial property is that D, not N, dominates: when two files are nearly identical (small D) the diff is almost linear and feels instantaneous, which is exactly the common case in version control. A refinement described in the same paper reduces memory to O(N) using a divide-and-conquer (linear-space) technique, so even large files do not exhaust memory.
LCS distance versus Levenshtein distance
"Edit distance" is a family of measures, and the difference between two of them explains why diff output looks the way it does. Levenshtein distance counts the minimum number of single-character insertions, deletions and substitutions needed to turn one string into another. LCS distance — the model behind line diff — allows only insertions and deletions; there is no substitution operation.
That single restriction is why a diff never shows a line as "changed in place." It shows the
old line as removed and the new line as added — two operations rather than one. The textbook
example transforms kitten into sitting: the Levenshtein distance is
3 (substitute k for s, substitute e for i, insert g), but the LCS distance is 5, because each
substitution must be expressed as a delete plus an insert. Tools that want to highlight
intraline edits run a second, finer diff within a changed line — but the line-level
decision is pure LCS.
Git's four diff algorithms
Git lets you pick the algorithm with --diff-algorithm. All four produce a
correct diff; they differ in which equally valid alignment they choose, which
changes how readable the result is.
| Algorithm | How it works | Best for |
|---|---|---|
| Myers (default) | Greedy shortest-edit-script search on the edit graph. | General use; fast and good enough almost always. |
| Minimal | Drops the Myers greedy heuristic to guarantee the provably smallest diff. | Small inputs where the absolute minimum matters; slower. |
| Patience | Matches only lines that are unique in both files, anchors on the longest increasing subsequence of them, then recurses. | Refactors and reorders, where Myers aligns the wrong braces or blank lines. |
| Histogram | An extension of patience that also handles low-frequency common lines; comparably fast. | A clean default alternative; tidy output on function moves. |
Patience diff was invented by Bram Cohen, the creator of BitTorrent. Its insight is that unique lines — a distinctive function signature rather than a closing brace — are the most meaningful anchors, so aligning those first and recursing into the gaps between them produces a diff that matches how a human reads the change. Histogram refines the same idea and is often the quietest on large refactors.
Line, word and character granularity
Diff algorithms compare a sequence of tokens, and you choose what a token is. The most common choice — and the one this tool uses — is the line. Lines are a natural unit for source code and configuration: they are meaningful, there are far fewer of them than characters (so the O(ND) work stays small), and a line-level result is easy to scan.
Word-level diff tokenizes on whitespace and suits prose, where a one-word edit in a long paragraph should not flag the whole line. Character-level diff is the finest grain, useful for highlighting the exact letters that changed inside a word, but it is noisy on anything larger. Many editors combine the two: a line diff to find changed regions, then a word or character diff inside each region to highlight the precise edit.
Reading the unified diff format
The unified diff is the format you see in git diff, patches and
pull requests. It opens with two file headers — the original marked --- and the
new marked +++ — and then groups changes into hunks. Each hunk
begins with a header of the form @@ -l,s +l,s @@, where the first pair is the
starting line and line count in the original file and the second pair is the same for the new
file.
Inside a hunk, every line carries a one-character prefix: a space for an
unchanged context line, a minus for a line removed from the original, and a
plus for a line added in the new version. By default a few unchanged
context lines (commonly three) surround each change so a patch still applies after
the file has drifted slightly. The older context diff format conveyed the
same information but printed the before and after blocks separately and marked changed lines
with !; the unified format is more compact because it interleaves the two sides,
and it has become the default.
Three-way merge and conflicts
A plain two-way diff cannot tell which of two differing files is "right." A
three-way merge adds the common ancestor as a reference. Tooling such as
diff3 compares both versions against that base: a change made on only one side
is applied automatically, while a region that both sides changed differently is reported as a
merge conflict — the familiar
<<<<<<< / ======= /
>>>>>>> markers in Git. Recognizing that a conflict is
simply "both sides edited the same lines relative to the ancestor" makes resolving them far
less mysterious.
Where diffing is used in practice
- Code review. Every pull request is a diff; reviewers read added and removed lines rather than re-reading whole files.
- Document and contract comparison. Comparing two revisions of an agreement, a policy or an article to see precisely what wording changed.
- Configuration drift. Diffing a server's live configuration against the known-good version to find unintended edits.
- Log and data analysis. Comparing two exports, two CSV snapshots or two log files to isolate exactly what moved between runs.
- Plagiarism and similarity detection. The size of the common subsequence is a direct measure of how alike two documents are.
In every case the question is the one Hunt, McIlroy and Myers answered: what is the smallest, clearest set of changes that turns the first text into the second?
The limits of line diff: moved blocks and noisy output
A line diff answers one precise question — the shortest sequence of line insertions and deletions between two files — and that framing has real blind spots worth understanding. The most common is moved code: if you cut a function from the top of a file and paste it at the bottom, a basic diff has no concept of "moved." It reports the block as removed in one place and added in another, doubling the apparent size of the change. Some tools add move detection as a separate pass on top of the diff; the underlying LCS result still treats the two copies independently.
A second limitation is alignment ambiguity. When a file contains many identical lines — blank lines, closing braces, repeated boilerplate — several different diffs can all be equally minimal, and a greedy Myers search may pick one that pairs the wrong brace with the wrong brace, making a tidy edit look scattered. This is exactly the problem the patience and histogram algorithms target by anchoring on unique lines first. A third is that line diff is blind to intraline change: edit one character in a long line and the whole line is flagged, which is why prose comparison often benefits from a word-level pass.
None of this makes line diff wrong — it is the right default for code and configuration — but knowing its assumptions explains why two tools can show the "same" change differently, and why switching algorithm or granularity sometimes turns a confusing diff into an obvious one.
Frequently asked questions
- What algorithm does this use?
- Line-by-line diff using the LCS (Longest Common Subsequence) algorithm — the same approach used by diff(1) on Unix, git diff, and most code review tools. Lines present in both texts are shown as unchanged; lines only in the original are marked as removed (red); lines only in the modified text are marked as added (green).
- Is my text uploaded to a server?
- No. The diff runs entirely in your browser with JavaScript. Your text never leaves your device and works offline once the page is loaded.
- Can I diff code?
- Yes. The tool diffs any plain text, including source code, configuration files, JSON, CSV, prose and markdown. It does not apply syntax highlighting, but the line-level diff correctly handles indentation and punctuation.
- How large a text can I compare?
- The LCS algorithm has O(n×m) time complexity, so very large files (thousands of lines) may be slow. For documents up to a few hundred lines the diff is instantaneous. For large files, consider a desktop diff tool (diff, vimdiff, VS Code compare) instead.
- What does "ignore whitespace" do?
- When checked, each line is trimmed before comparison, so a line with only a leading-space change is treated as unchanged. This is equivalent to diff -b on Unix — useful for comparing code that was reformatted or re-indented.