What a diff actually tells you
A diff answers one question precisely: what is different between these two versions? Not what is better, not what is correct — only what changed. That sounds modest until you have tried to eyeball two near-identical pages of text and convince yourself nothing slipped through.
The common jobs: checking what an editor changed in your draft, comparing a contract against the version you thought you agreed, seeing what a tool rewrote when you ran text through it, and confirming that a copy-paste actually copied everything.
How the comparison works
Both versions are split into lines, and the tool finds the longest common subsequence — the largest set of lines that appear in both, in the same order. Anything outside that set is what changed. It is the same idea behind the diff command and behind every code review you have ever seen.
One consequence is worth understanding: a diff has no concept of a line being moved. If you cut a paragraph from the top and paste it at the bottom, you will see it removed in one place and added in another, not relocated. That is not a limitation of this tool so much as of the approach itself.
Where a removal and an addition sit next to each other, they are paired into a single changed row and compared again at word level, so you see the two words that differ rather than two whole sentences painted red and green.
The two options that stop false alarms
Ignore capitals treats Hello and hello as the same line. Useful when something has been passed through a tool that normalises case, or when you only care about substance.
Ignore spacing collapses runs of spaces and tabs and trims the ends of lines. This is the one that saves the most time. Invisible trailing spaces and a switch between tabs and spaces will otherwise light up every line as changed when nothing meaningful happened at all.
Both options change only what counts as a match. The text shown is always your original, spacing and capitals intact.
A note on speed and size
Identical opening and closing sections are matched and skipped before the real work starts, which is why a one-line change inside a four-thousand-line document is found instantly. Two documents of a few thousand lines that share almost nothing are the genuinely hard case; past a certain size the tool says so plainly and shows the whole thing as removed and added, rather than quietly producing a line-up it did not really compute.
Questions people ask
Does it work on code?
Yes. It is line-based and format-agnostic, so JSON, HTML, CSV and source code all compare fine. It does not colour syntax, and it will not understand that reordering two independent functions changes nothing.
Can I compare two files?
Not by uploading them — open each one and paste the contents in. That is a deliberate limit rather than a missing feature: keeping it to paste means there is never a file to send anywhere.
Why is one word highlighted when the whole line looks different?
Because only that word changed. Word-level highlighting runs inside each changed pair, so a long sentence with one substituted word shows exactly that. If a line is highlighted end to end, it really is different end to end.
Does it handle different line endings?
Yes. Windows files end lines with a carriage return and a newline, Mac and Linux files with a newline alone. Pasting one of each would otherwise report every single line as changed. Line endings are normalised before comparison, so they never show up as differences.
Is anything sent anywhere?
No. The comparison is JavaScript running on your device, and neither version leaves the page. There is no request from this tool at any point — worth knowing given that the things people compare are often drafts, contracts and correspondence. The site’s theme loads its web fonts from Google on every page, as most WordPress themes do, and that is separate from this tool.