Compare Two Texts and See What Changed
Paste the old version on top and the new one below. The comparison runs as you type and marks what was removed, what was added, and which words inside a changed line actually moved.
Result
Lining the two texts up is the hard part
The obvious way to compare two texts is to walk both at once and flag every line where they disagree. Insert a single line at the top of a file and that approach reports every remaining line as changed. It is correct and it is useless.
Real diff tools solve a different problem first: find the longest sequence of lines that appears, in order, in both texts. That is the longest common subsequence. Anything outside it is a deletion from the left or an insertion on the right, and the alignment falls out of that.
The textbook implementation fills a table with one cell per pair of lines, so both time and memory grow with the product of the two line counts. Git and most editors use Myers' algorithm instead, whose cost scales with the number of differences rather than the size of the files — much faster in the normal case where two versions are mostly the same. This tool uses the table, with one shortcut that does most of the work: identical lines at the very start and the very end are matched off before the table is built.
Where that gives up
If more than roughly 1,500 lines on each side still differ after the common head and tail are removed, the table gets too large and the tool stops trying to align them. It falls back to marking the whole middle as removed and then re-added, and the note under the buttons says so. At that size you want git diff or a desktop merge tool, not a text box.
Whitespace is invisible and load-bearing
Two lines that look identical frequently are not. Windows ends lines with a carriage return followed by a line feed; everything else uses a line feed alone. This tool normalises both to a line feed before comparing, so a file pasted from a Windows editor never shows up as 100% different for that reason alone.
Trailing spaces are the other classic. Ignore leading and trailing spaces handles them, but it also hides indentation changes — and in Python, YAML or Makefiles the indentation is the change you were looking for. Leave it off when structure depends on spacing.
A text ending with a newline and one that does not are treated as identical here, because the final newline is read as a terminator rather than as an empty last line. Git is stricter and prints \ No newline at end of file. If that distinction matters for what you are doing, check it somewhere else.
The word highlighting is an educated guess
When a removed line sits directly above an inserted one, the same algorithm runs again across the words inside them and shades only the parts that actually moved. It is far easier to read than two solid blocks of red and green.
It is still a guess. The pairing is made by position alone — first removed line with first inserted line, and so on. Rewrite a paragraph and reorder its sentences and the pairing becomes nonsense. The tool refuses to highlight when two paired lines share less than about a third of their characters, which catches the worst cases but not all of them. When the highlighting looks wrong, turn it off and read the lines whole.
Three things to check before trusting the result
- Very long single lines. Minified JavaScript, a one-line JSON blob or a document with no hard line breaks all count as one line. Change a character in the middle and you get "1 removed, 1 added" with the whole thing shaded. Line-based diffing has nothing useful to say about a file with three lines in it.
- Lookalike characters. A non-breaking space, a curly quote pasted from a word processor, or a Cyrillic letter that renders like a Latin one will all read as a difference while looking identical on screen. If a line is marked changed and you cannot see why, that is usually the cause.
- Structure the tool cannot see. The comparison is strictly textual. It does not know that a moved function is the same function, that two JSON objects with reordered keys are equivalent, or that a variable was renamed. Structural comparison needs a parser for the specific language.
What the copy button produces
Copy diff gives you the familiar shape — a leading +, - or space on every line — but without the @@ hunk headers and file names that a real unified diff carries. It is built for pasting into a review comment or a chat message. patch and git apply will reject it.
Frequently asked questions
Is my text uploaded anywhere?
No. The comparison runs in JavaScript inside your tab. Nothing is sent to a server, nothing is stored, and closing the page discards both texts. You can confirm it by loading the page and then disconnecting from the network — the tool keeps working.
Why does it say lines are different when they look the same?
Almost always an invisible character: a trailing space, a non-breaking space, a curly quote, or a tab where you expected spaces. Turn on "Ignore leading and trailing spaces" to rule out the first one. If that does not fix it, the difference is inside the line.
Can it compare two files instead of pasted text?
Not directly — there is no file picker. Open the files in any editor and paste the contents in. For files large enough that pasting is awkward, a local diff tool will serve you better anyway.
What does the similarity percentage mean?
It is the share of lines that matched, counted against both texts: unchanged lines times two, divided by the total line count of both sides. It measures whole lines, so changing one word in every line gives 0% similarity even though the texts are nearly identical.
Can I use the output as a patch file?
No. The copied diff has the plus and minus prefixes but no hunk headers, so patch and git apply will refuse it. Use it for review comments and chat, and generate a real patch with git diff when you need one that applies.
Last updated September 19, 2026