Text diff

What this tool does

A diff answers one question precisely: what would have to change to turn one text into another? Paste the original on the left and the newer version on the right, and the tool shows every deleted line, every added line, and — inside a line that was modified — the exact words that differ, highlighted. It is the same question git answers on every commit, computed with the same family of algorithm, entirely in your browser.

That last part matters more for a diff tool than for most: the things people compare tend to be private — two versions of a production config, a query before and after an optimisation, the response body that worked yesterday against the one failing today. Here they never leave your device.

Side-by-side or unified

The two views show the same comparison arranged differently. Side by side puts the original on the left and the changed text on the right, with matching lines aligned — the natural way to read a document revision. Unified interleaves them in one column, deletions prefixed with a minus and additions with a plus — the format git log and code reviews use, more compact and better when changes are sparse. Both views mark the original line numbers in the gutters, so a finding here maps straight back to your file.

How the diff is computed

The tool implements the Myers difference algorithm, published in 1986 and still the default in git today. It finds a shortest edit script: the minimum number of line deletions and insertions that transforms one text into the other. That minimality is what makes a diff readable — a naive comparison that resynchronises badly after a change reports whole blocks as replaced, where Myers pinpoints the two lines that actually moved.

Lines are compared first, then each pair of changed lines is compared again at the word level to produce the highlights. One honest limitation: when two texts have almost nothing in common, the minimal-script search would cost more memory than a browser tab should spend, so beyond an edit distance of two thousand the tool falls back to showing everything as replaced — and says so with a notice rather than silently.

The whitespace and case options

Many differences are real but irrelevant. A file reindented from tabs to spaces, a trailing space added by an editor, a keyword recapitalised — all genuine changes, all noise when what you want to know is whether the logic changed. The two checkboxes handle the common cases: one sets aside whitespace at the edges of each line, the other sets aside letter case. They affect only what counts as a change — the display always shows each line exactly as you pasted it.

• Ignore edge whitespace — leading and trailing spaces and tabs are dropped before comparing, so an indentation-only change stops showing as a modified line. Whitespace inside a line still counts.
• Ignore case — lines and words that differ only in capitalisation compare as equal. Useful for SQL keywords, HTTP header names, and other case-insensitive contexts.

The patch you can copy

The copy button produces the comparison in unified diff format — the lingua franca of code changes. Each block of change (a hunk) starts with an @@ header naming the line numbers it covers, deleted lines start with a minus, added lines with a plus, and a few unchanged context lines surround each hunk so the change can be located even if the file has shifted slightly.

--- a
+++ b
@@ -1,3 +1,3 @@
 server:
-  port: 8080
+  port: 9090
   timeout: 30

This text can be pasted into a ticket or a code review, mailed to a colleague, or applied mechanically: saved to a file, "git apply" or the Unix patch command will replay the change onto the original. One detail worth knowing: a file that does not end with a newline gets the marker "\ No newline at end of file" in its patch — the tool reproduces that behaviour, because a missing final newline is a real difference and pretending otherwise makes patches that do not apply.