How to use
- Paste the original text on the left and the changed text on the right.
- Differences appear immediately; added lines are green, removed lines are red.
- Turn on Ignore leading/trailing whitespace when indentation changed but content did not.
- Collapse unchanged lines hides long stretches of identical content, keeping three lines of context around each change.
About comparing text
The obvious way to compare two texts — line 1 against line 1, line 2 against line 2 — falls apart the moment a line is inserted. Everything after the insertion shifts by one, and every line gets reported as modified. The output is technically correct and practically worthless.
What produces a readable diff is finding the longest common subsequence: the longest set
of lines appearing in both texts in the same order, though not necessarily adjacently. Those
lines are the unchanged ones; everything else is an insertion or a deletion. This is how
git diff and every other serious comparison tool works.
The cost is that the classic algorithm builds a table of every line on one side against every line on the other. Two five-thousand-line files mean twenty-five million cells — enough to make a browser tab unresponsive. The fix that makes it practical is to strip the identical leading and trailing lines first, because in real comparisons most of the file has not changed. Two twenty-thousand-line files differing in one line reduce to a comparison of roughly one line against one line.
One thing worth knowing when a diff looks unexpectedly large: line endings. A file saved on Windows ends its lines with a carriage return plus a line feed; on Unix, just a line feed. Those are genuinely different bytes, and a comparison that does not normalise them reports every single line as changed. This tool normalises them, which is almost always what you want — but if you are specifically hunting a line-ending problem, that is exactly the difference it will hide.