Diff Checker

What is this tool?

A free online diff checker — a text compare tool that shows exactly what changed between two versions of anything written in lines: code, configuration, contracts, essays, SQL dumps, translations. It finds the minimal set of added and removed lines using the same algorithm family asgit diff, pairs up modified lines, and highlights the changed words inside them, so a one-character edit in a long line is a small bright mark rather than two walls of color.

Neither text ever leaves your browser. The comparison runs client-side in a background worker; the compare side of the page works the same if you go offline after loading it. That matters for a diff tool more than most — the things people diff (contracts, configs with credentials, unreleased code) are exactly the things that shouldn't be uploaded to a random website. Here they can't be: there is no server to receive them.

How to use it

• Paste the original text on the left and the changed version on the right — or use Open file… / drag-and-drop (up to 5 MB per side).
• The diff updates live as you type. Removed lines are red, added lines are green, and modified lines show word-level highlights — narrowed to the exact characters when two lines are close variants.
• Lines that merely moved show up in blue with a ⇄ moved to / moved from marker instead of pretending to be a removal plus an unrelated addition.
• Long unchanged stretches fold away automatically — click show unchanged lines to expand them.
• Switch between Side by side, Unified (one column, like a code review), and Patch (raw unified-diff text you can copy or download).
• Ignore whitespace compares with runs of spaces and tabs collapsed — ideal after re-indenting. Ignore case does what it says.
• Swap ⇄ flips the two sides; your last texts are remembered locally on your device.

Reading the diff

• Red lines exist only in the original — they were removed.
• Green lines exist only in the changed text — they were added.
• A red/green pair on the same row is a modified line: the brighter marks show precisely what changed inside it — whole words when a word was replaced, single characters when it's a close variant like a typo.
• Blue lines are moves: the same line was deleted in one place and reappears unchanged in another, and the ⇄ note tells you exactly where it went or came from. Trivial lines (a lone }, end…) are deliberately exempt so they never masquerade as moves.
• Hatched cells mean the line has no counterpart on that side.
• The summary counts them separately: removed and added are whole lines, changed are pairs, moved are relocations.

Side-by-side vs unified

Side-by-side shows the original on the left and the changed text on the right with matching lines aligned — best for reviewing edits in prose or config, where you want to read both versions. Unified interleaves removals and additions in one column, prefixed with − and+ — the format every code review tool uses, best for code and for narrow screens. The same diff backs both; switching views never recomputes it.

The patch format, explained

The Patch tab exports the diff inunified diff format — the lingua franca understood by git apply, patch, and every code review tool. It reads like this:

--- original
+++ changed
@@ -2,7 +2,7 @@
 port: 8080
-retries: 3
+retries: 5
 timeout: 30s

• --- /+++ name the two files.
• Each @@ -2,7 +2,7 @@ hunk header says: this block starts at line 2 and covers 7 lines of the original (-) and 7 of the changed text (+).
• Lines starting with a space are unchanged context (three lines of it around every change); - lines were removed, + lines added.
• \ No newline at end of file flags a file whose last line has no trailing newline — a classic source of mystery one-line diffs.

One honest caveat: with ignore whitespace orignore case switched on, equal-but-not-identical lines appear as context, so the patch is for reading, not for piping into patch — the same trade-off asdiff -w.

Under the hood

The comparison uses Myers' O(ND) diff algorithmwith the linear-space middle-snake refinement — the algorithm behind classic Unix diff and git. It provably finds ashortest edit script, so you never see the spurious add/remove pairs cruder tools produce. Lines are interned to integers first (so comparing two lines costs one integer check), the common head and tail of the two texts are stripped before the algorithm even starts, and modified line pairs get a second, word-level Myers pass to find the in-line highlights — then a third, character-level pass refines each changed region, gated by a similarity check so a typo marks one letter while a replaced word stays one clean mark. Moved lines are found the waygit diff --color-moved finds them: deletions and insertions with identical content are matched up before anything else, grouped into blocks, and filtered by substance. It's all written from scratch in TypeScript for this site — the core is pure, unit-tested (including a fuzz suite that checks minimality against a brute-force reference), and runs in a Web Worker with a watchdog so even a pathological input can't freeze the page.

FAQ

Is it free? Yes — free, no sign-up, no limits beyond a 100,000-line cap per side.

Is my text uploaded anywhere? No. Both texts stay in your browser; the only thing stored is your last comparison, in your own browser's local storage, so it's still there when you come back. Nothing is sent to this server or anyone else's.

Does it handle Windows vs Unix line endings?Yes — CRLF and LF are treated as the same line ending, so two files that differ only in line endings compare as equal instead of as two entirely different files.

How does it decide something "moved"? A deleted line that reappears as an added line elsewhere is matched into a move, block-wise. It doesn't have to be byte-identical: a line that moved and picked up a small edit or different indentation is still recognised (by character similarity), and the bright marks inside the blue rows show exactly what changed on the way. Only lines with enough actual content qualify — a relocated function shows as a ⇄ move; a stray closing brace that happens to match one somewhere else never does. In the exported patch, moved lines are ordinary -/+ pairs — the unified format has no move concept.

Can I diff JSON with it? Yes, but for JSON with reordered keys, first run both documents through theJSON formatter with sorted keys — then the diff shows real changes instead of formatting noise.

Can I apply the exported patch? With the ignore options off, the Patch tab produces standard unified-diff output with correct hunk headers and no-newline markers. Save it and apply with patch -p0 < changes.patch orgit apply changes.patch (paths permitting).

Why do two big, completely unrelated texts time out?Diff cost grows with the number of differences, not just text size. Comparing unrelated documents means everything is a difference — the tool cuts the run off after a few seconds rather than letting the tab spin. Realistic inputs (two versions of the same document) compare in milliseconds even at tens of thousands of lines.