Fast, practical, browser-based developer tools
Compare two blocks of text instantly and inspect exactly what changed. This browser-based text diff checker is useful for reviewing revisions, comparing code snippets, checking document updates, and spotting line-by-line differences quickly.
A text diff checker helps identify edits between two versions of content without manual review. It is useful for code snippets, document revisions, article updates, notes, logs, configs, and many other text comparison workflows.
This text diff checker is designed to work directly in your browser during normal use. That makes it useful for quick revision reviews, local comparison tasks, and lightweight editing workflows.
For more details about site usage and analytics, read our Privacy Policy.
Paste the original version into the first box and the updated version into the second box, then run the comparison. The tool highlights removed, added, and unchanged lines so you can review differences quickly.
Original: hello world version one Updated: hello world version two
A diff is not a character-by-character overlay of two files. Underneath, it solves a precise mathematical problem: find the longest common subsequence (LCS) of the two texts, or equivalently the shortest edit script — the smallest set of line insertions and deletions that turns text A into text B. Everything the tool keeps is the common subsequence; everything else is reported as an insert or a delete.
The algorithm behind git and most modern tools is Eugene Myers' 1986 diff algorithm, described in his paper "An O(ND) Difference Algorithm and Its Variations." It models the comparison as a shortest-path search through an edit graph and finds a path with the fewest edits. The key thing to internalise is that a diff is minimal by a formal metric — fewest inserted and deleted lines — not necessarily the change a human would describe. The two often coincide, but not always, and the cases where they diverge are where diff output starts to look strange.
The same LCS idea runs at different granularities, and choosing the wrong one is the most common reason a diff looks noisier than the edit deserves.
Match the granularity to the edit: line diff for code, word diff for editing an article, character diff only for short strings where you need to see the exact characters that moved.
The single most common real-world diff complaint has nothing to do with your edits: it is
line-ending and whitespace noise. Windows terminates lines with
CRLF (\r\n); Unix and macOS use a bare LF
(\n). Re-save a file on the other operating system and every single line now
ends with a different, invisible byte — so a line diff reports every line as
deleted and re-added even though nothing you can see has changed.
Trailing whitespace and a tabs-versus-spaces indentation switch do exactly the same thing:
the characters differ even when the rendered text looks identical. The fixes, in order of
preference: normalise line endings before comparing; use a whitespace-insensitive compare
(git diff -w, also written --ignore-all-space); or, better, stop
the problem at the source by configuring core.autocrlf or committing a
.gitattributes file so the repository stores one consistent line ending for
everyone.
Cut a function from the top of a file and paste it, unchanged, at the bottom. You made one conceptual edit — a move — but the diff explodes: the block shows as a large deletion where it used to be and an equally large addition where it now sits, roughly doubling the apparent size of the change.
This is not a bug. The LCS model has no vocabulary for "moved" — its only operations are
insert and delete, so a relocation can only be expressed as a delete in one place plus an
add in another. Some tools bolt a move-detection heuristic on top (git's
--color-moved, for example) to recognise that an added block matches a deleted
block and colour it differently, but the underlying diff still records two separate edits.
When a small reorganisation produces a giant diff, a move is almost always the reason.
A minimal edit script is not unique. Several genuinely different edit scripts can share the same minimal length, so two standards-conforming diff tools can show visibly different diffs of the same two files and both are correct — each found a shortest path, just not the same one. This surprises people who assume a diff has one canonical answer.
On top of that, many tools deliberately do not return raw Myers output. Git ships alternative strategies — patience diff and histogram diff — that add heuristics to anchor on unique lines and pick hunks a human is more likely to find readable, especially around repeated boilerplate like closing braces or blank lines. They can produce a different-looking (but still valid) diff than the default Myers algorithm. So "the diff" of two files is really "a diff": correct, minimal, but one of several defensible presentations.
The longest common subsequence of the two texts — equivalently, the shortest edit script of insertions and deletions that turns one into the other. Git and most tools implement Eugene Myers' 1986 algorithm, which finds a path with the fewest edits through an edit graph. The result is minimal by that formal metric, not necessarily the change a human would describe.
Almost always a line-ending mismatch. Windows uses CRLF
(\r\n) and Unix/macOS use LF (\n), so a file
re-saved on the other OS has a different invisible byte at the end of every
line — a line diff then reports all of them as changed. Normalise line endings first,
or use a whitespace-insensitive compare.
Line diff for code and config: fast and readable, but it flags the whole line even for a one-character change. Word diff for prose, so a single edited word doesn't light up the entire paragraph. Character diff only for short strings, where seeing the exact characters that moved is worth the noisier output.
Because the LCS model only has insert and delete operations — it cannot represent a
"move." A relocated block is therefore recorded as a deletion in its old position and
an addition in its new one, doubling the apparent change. Some tools add a
move-detection layer (for example git's --color-moved) on top of the raw
diff.
Normalise the text first, or use your tool's ignore-whitespace option — in git,
git diff -w (--ignore-all-space) or
--ignore-space-change. For a repository, configure
core.autocrlf or a .gitattributes file so line endings stay
consistent and the noise never appears.
Because a minimal edit script is not unique: several different edit scripts can share the same minimal length, so two conforming tools can each pick a valid shortest path and display different-looking diffs. Many tools also add heuristics — git's patience or histogram diff — to choose more human-readable hunks than raw Myers output.