Text Diff

What this does

Paste an original into the left box and a changed version into the right, and the table below fills in with the two texts aligned line by line: matching lines sit on the same row with their line numbers on either side, a line that was rewritten in place shows both versions on one amber row, and lines that exist in only one version get a coloured cell with a blank opposite it. It updates about 60 ms after you stop typing, entirely inside the page — no request is made, which is why it is safe for production config and logs.

How do I compare two blocks of text?

1. Paste the old version into Original.
2. Paste the new version into Changed.
3. Read the table: red on the left means the line was removed, green on the right means it was added, amber across both means it was changed.
4. Check the counter above the table — it reads +3 −1 ~2 for three added, one removed and two changed lines.
5. Use the copy button to take the whole comparison as a plain-text patch.

What does the output look like?

Original            Changed
1  The quick        1  The quick
2  brown fox        2  slow brown fox   (changed)

copied patch:
  The quick
- brown fox
+ slow brown fox

In the copied patch, unchanged lines carry two leading spaces, removals a - and additions a +, with the removal always printed first so it reads like a unified diff when pasted into a pull request or a chat message. The copy button stays disabled while the two sides are identical.

How does the line matching work?

It is a longest-common-subsequence diff — the same family of algorithm as Unix diff. A dynamic-programming table finds the largest set of lines that appear in both texts in the same order; everything the table does not cover is reported as an addition or a deletion. That means a moved block shows up as a deletion in one place and an addition in another rather than as a "move", and a single edited word makes the whole line count as removed and re-added. This is a line diff only; there is no character-level highlight inside a line.

What do the two checkboxes do?

Ignore leading/trailing whitespace trims each line before comparing, so re-indented code or a stray trailing space no longer registers as a change. Ignore case lowercases both sides before comparing, which is what you want for re-cased copy or for case-insensitive identifiers. Both affect only the comparison — the table always shows your original text, spacing and capitalisation intact. The trim option doubles as the fix for a common surprise: text is split on \n alone, so a Windows-saved file pasted against a Unix one leaves a carriage return on every line and every row lights up until you tick it.

How large a comparison can it handle?

The table is O(lines × lines) in both time and memory, so cost grows with the product of the two sides. A few hundred lines each is instant; a thousand against a thousand is a noticeable pause; ten thousand against ten thousand will allocate a hundred million cells and is best left to git diff on the command line. If the two sides are structured data rather than prose, it usually pays to normalise first — pretty-print both with the JSON formatter or the YAML converter, or run them through sort lines when order is not meaningful, so the diff shows real changes instead of formatting noise.