Text Diff

Text Diff runs Myers' diff algorithm — the same edit-script algorithm behind git diff, diff -u and most code-review tools. Given two sequences it finds the shortest list of insertions and deletions that turns the first into the second, which is what makes the output feel like a description of what you changed rather than a list of every position where the two strings happen to disagree.

Everything happens in your browser. Nothing you paste is uploaded, logged or sent anywhere — the page has no server component at all, and it keeps working with the network switched off.

Line, word and character comparison

The Compare by toggle chooses what counts as one unit of change:

• Line — the default, and the right choice for code, configuration files and anything else that is naturally organised into lines. Lines are split the way git splits them: \r\n and a lone \r are treated as \n, and a single trailing newline ends the last line instead of creating an empty one. Two texts that differ only by a trailing newline therefore compare as identical.
• Word — compares whitespace-delimited words across the whole text, which is what you want for prose. Rewriting one sentence of a paragraph shows up as that sentence's words changing rather than the entire paragraph turning red.
• Character — compares individual characters, useful for short strings: an ID with one digit wrong, a hash that does not match, two nearly-identical URLs. Characters are counted by code point, so an emoji or a CJK extension character is one unit rather than two halves of a surrogate pair.

Line comparison also runs a second, word-level pass inside any line that was changed rather than purely added or removed, so you can see which words moved without leaving the line view. That is why a changed line is marked ~ on both sides while a removed line is marked − and an added one +: the three states are distinguished by symbol and by the intra-line highlight, not by colour alone.

A worked example

Comparing this original:

The quick brown fox
jumps over the lazy dog
and keeps on running
to the end of the field

against this modified version:

The quick brown fox
leaps over the lazy dog
and keeps on running
past the end of the field
into the woods

gives 3 added, 2 removed, 2 unchanged. Two lines were edited — each counts once as removed and once as added, which is the same convention git diff --stat uses — and one line was appended. The copy button produces the standard unified form:

--- Original
+++ Modified
@@ -1,4 +1,5 @@
 The quick brown fox
-jumps over the lazy dog
+leaps over the lazy dog
 and keeps on running
-to the end of the field
+past the end of the field
+into the woods

At character level, the classic kitten → sitting example resolves to five operations: delete k, insert s, keep itt, delete e, insert i, keep n, insert g — two deletions and three insertions around three unchanged runs.

Ignoring whitespace and case

The two Ignore checkboxes change how two pieces of text are compared, never how they are displayed. Ignoring whitespace collapses runs of spaces and tabs to a single space and disregards leading and trailing whitespace, so a re-indented block stops drowning out the one line that actually changed. Ignoring case makes Hello and hello equal.

Because only the comparison is normalised, the panels still show exactly the text you pasted — you never see a version of your input that you did not write. One consequence is worth knowing: with either option on, the unified diff can contain context lines that are not byte-identical between the two sides, so the output is a description of the change rather than a patch you could feed to git apply.

Large inputs

Myers' algorithm costs time proportional to the size of the inputs multiplied by the edit distance between them, so it is fast when two texts are similar and expensive when they are not. Text Diff strips the common opening and closing sections before searching, which is what keeps ordinary edits cheap: a three-thousand-line document with a single changed line reports 1 added, 1 removed and 2,999 unchanged without ever searching the unchanged bulk.

For inputs with no meaningful relationship, the search is capped at an edit distance of 1,200 and at 40,000 tokens. Past either bound the tool stops looking for a minimal alignment and reports the comparison as one wholesale replacement, flagged in the stats bar as “Too different to align”. That is a deliberate ceiling rather than a hang: two unrelated documents have no meaningful alignment to find, and pretending otherwise would freeze the tab.

Sharing a comparison

Copy link packs both texts and all four settings into the part of the URL after the #. Fragments are never transmitted to a server by the browser, so a shared link carries your text between people without it passing through anyone's logs. Very large inputs cannot be shared this way — beyond about 50,000 characters the link stops being a usable URL, and the button is disabled rather than producing one that silently breaks.

What it is good for

• Code review outside a repository — comparing a snippet from a bug report with what is actually in the file, or two versions of a config someone pasted into chat.
• Document revision — seeing exactly what an editor changed in a draft when you have two files and no track-changes history.
• Configuration drift — lining up a working config against a broken one. Ignoring whitespace is usually the right first move here.
• Checking near-identical strings — API keys, hashes, long URLs and identifiers, where character comparison finds the one wrong character faster than reading them side by side.