How to use it
- Paste the original on the left and the changed version on the right, or drop a file onto each side.
- Press Compare.
- Read the summary, then the Differences you cannot see box if there is one.
- Use the switches to ignore line endings, whitespace or case and narrow down what really changed.
The difference you came here to find is usually invisible
Most of the time a diff tool is doing something easy: two paragraphs differ, it colours them, you move on. The times it matters are the other ones — when two values look completely identical, refuse to match, and nothing on screen explains why.
That is the case this page is built for. When two lines are the same once you normalise them but are not the same as raw text, it does not just mark the line as changed. It works out which invisible thing is responsible and says so.
The five usual suspects
Line endings. A line break is one character on macOS and Linux, two on Windows. Open a file on the other platform, save it, and every single line now differs from its counterpart although nothing visible changed. This is the most common reason a diff turns entirely red when you were expecting three changes.
Trailing whitespace. Spaces at the end of a line have no appearance at all. They survive copy and paste, they get committed, and they make otherwise identical lines differ. This page draws them as visible dots so you can see how many there are.
Non-breaking spaces. A space that stops a line breaking at that point. It looks exactly like an ordinary space and is a different character. Text pasted out of word processors and web pages is full of them, and they are a common reason a name or a reference number fails an exact-match lookup.
Zero-width characters. Characters with no width whatsoever. They arrive from PDFs, from web pages and from editors that insert them to control line breaking. You cannot see them, you cannot select them reliably, and they break comparison.
Accents stored two ways. An accented letter can be one character, or a plain letter followed by a combining mark. Both render identically. macOS and Windows have historically preferred different forms, so text copied between them produces values that look the same and never compare equal.
Why the tool shows you the characters rather than cleaning them up
It would be easy to strip trailing spaces, normalise line endings and compare what is left. Some tools do exactly that, and it is the wrong default here: it would hide the thing you are trying to find. If your two configuration files differ only by line endings, that is the answer, not noise to be swept away before showing you an answer.
So the comparison is done on the text as given, with the differences named, and the switches are there for when you have understood the cause and want to see past it. The summary always says what was ignored, so a comparison that came back clean never came back clean for a reason you had forgotten about.
Files are read as bytes, deliberately
The convenient way for a browser to read a text file silently removes a byte order mark if it finds one, and can alter line endings on the way through. For most tools that is harmless. For this one it would destroy evidence — a byte order mark is a real difference between two files and a frequent cause of a mismatched first line.
So files here are read as raw bytes and decoded explicitly, with the byte order mark preserved and shown. We learned this the hard way on our CSV tools, where the convenient method quietly broke a claim the page was making about not touching your data.
What it does not do
It compares line by line, not word by word inside a line, so a changed line is shown as a removed line and an added one. It has no opinion about syntax, so it will not tell you that two pieces of JSON are equivalent with their keys in a different order. And it does not merge — it shows you what differs and leaves the decision to you.