How to use it
- Paste the original text, then a line containing only
<<<, then the changed text. - Added lines appear in green with a
+, removed lines in red with a-. - Enable Changes only to hide the unchanged context.
How a diff actually works
The output looks like a list of edits, but the algorithm never searches for edits. It searches for sameness.
Given two sequences of lines, it finds the longest common subsequence — the largest set of lines appearing in both, in the same relative order, not necessarily adjacent. Whatever is left over is the difference: lines present only on the left were removed, lines present only on the right were added. A "changed" line is simply a removal and an addition that happen to sit next to each other; the algorithm has no concept of modification at all.
This is why diff output sometimes looks odd. Insert a line at the top of a file and the tool may show a whole block as removed and re-added, because a different alignment happened to yield a longer common subsequence. The result is correct — it is a minimal edit script — just not the one a human would have written.
The cost is a table of size m × n, one cell per pair of lines. That is fine for a few thousand lines on each side and becomes noticeably slow well before you reach a large source file, which is the honest limit of a browser-based tool.
Line-level versus character-level
This is a line diff, the same granularity git diff uses by default. Change one character and you see the entire line marked removed and the new version marked added.
That coarseness is a deliberate trade. Line diffs are fast, deterministic, and match how developers already read changes. Character-level diffs are better for prose and worse for code — they produce visually noisy output on reflowed text and cost considerably more to compute. When you need a word-level view of a paragraph, the practical move is to put each sentence on its own line first.
The options that reduce noise
Ignore trailing whitespace is on by default, because trailing spaces are invisible and almost never the change you care about. An editor that strips them on save will otherwise make every touched line look modified.
Ignore case compares case-insensitively while still showing the original text. Useful for comparing SQL keywords or environment variable names across environments where capitalisation is inconsistent but irrelevant.
Changes only drops the matching lines. On a large file with a small edit this turns hundreds of lines of context into the two lines you actually wanted to see.
What this is good for
Comparing two API responses to find the field that changed. Checking a config file against the version in production. Verifying that a refactor did not alter generated output. Confirming that two supposedly identical exports really are identical — which the status bar answers immediately, rather than making you read the whole thing.