Two texts that look identical rarely are, and finding the difference by eye is a task humans are spectacularly bad at. This tool compares line by line and marks what was added and removed. The interesting part is that "what changed" is a question with more than one right answer.
The invisible difference that makes everything look changed
If a diff reports that every single line changed while the text plainly did not, the answer is almost always line endings. Windows ends lines with a carriage return and a line feed; Unix, Linux and macOS use the line feed alone. Both look like nothing at all on screen.
The effect is total. Split "uno\ndue\ntre" and "uno\r\ndue\r\ntre" into lines and you get ["uno","due","tre"] against ["uno\r","due\r","tre\r"] — every line now carries an invisible passenger, and only the last one, without a trailing break, matches. One line in three. The texts are the same; the bytes are not.
This is why git has autocrlf settings and why teams argue about them. If you are comparing a file from a colleague on Windows against yours on a Mac, normalise the endings before you look for meaning in the result.
There is no single correct diff
This surprises people who assume a diff is a fact. It is not — it is one answer among several equally minimal ones. If a line is deleted from a run of identical lines, nothing in the text says which one went. The algorithm picks, and different algorithms pick differently.
Add a function to a source file and the diff may show your new function as added, or it may show your closing brace as added and the following function's brace as removed — both are minimal, one is comprehensible. This is exactly why git ships several algorithms: the default Myers is fast, while patience and histogram produce diffs that align better with how a human sees the change. None of them is more correct. They are optimising for different definitions of a good answer.
Why big comparisons hit a wall
The classic algorithm builds a table of every line in A against every line in B, which costs time and memory proportional to the two lengths multiplied together. Two 12,000-line files need a table of 144 million cells: over a gigabyte of memory and nearly two seconds of work. On a phone, that is a dead tab.
The saving grace is that real comparisons are rarely random. Two versions of a document usually share a long identical head and tail, and those lines need no table at all — they are equal by inspection. Stripping them first is the first move in every serious diff implementation, and on two 12,000-line files that differ in one place it takes the table from 144 million cells down to a handful.
That handles the normal case. It does not help when two large texts are genuinely different throughout, because then there is no common head or tail to strip. This tool draws a line there and tells you rather than trying and dying: if the comparison is too large after trimming, you get a message. That is a deliberate choice — a tool that freezes your browser is worse than one that admits its limits.
Lines are the wrong granularity for prose
This tool compares whole lines, which suits code, configuration and anything where a line is a meaningful unit. It suits prose badly. Change one word in a paragraph that lives on a single line and the diff marks the entire paragraph as removed and re-added, which is technically true and practically useless.
The fix in that situation is to work with text that has one sentence per line, or to reach for a word-level diff. It is worth knowing which kind you are looking at: a line diff on a wrapped document tells you a paragraph changed, and nothing about what changed inside it.
Common questions
Is my text sent to a server?
No. This tool is marked "client": both texts are compared in your browser tab and neither leaves your machine. That matters more than usual here, because comparing two versions of something means you have two versions of it — contracts, drafts, configuration files with credentials in them.
Why does it say every line changed when they look the same?
Line endings, almost certainly — see above. The other candidate is trailing whitespace, which is just as invisible and just as fatal to a comparison. If your editor can show invisible characters, turn that on and look at the end of the lines.
Why is there an extra empty line at the end?
Because the text ends with a line break. Splitting "a\nb\n" on newlines yields three pieces — "a", "b" and an empty string after the final break. It is not a bug in the diff; it is what a trailing newline means. Unix convention says text files should end with one, so this is very common and usually not worth chasing.
Can it compare two files rather than pasted text?
Not here — this is a paste-in tool. For files, and particularly for anything under version control, use git diff: it handles line endings, offers the better algorithms mentioned above, and can show word-level changes within a line. This tool is for the quick comparison where opening a terminal is more effort than the question deserves.
Does it ignore whitespace?
No. Every character counts, including trailing spaces and indentation. That is the right default for a general tool — sometimes whitespace is the entire change you are hunting for — but it does mean a reindented file will diff as completely rewritten. If that is your situation, git diff -w ignores whitespace and will show you what actually moved.