Text compare, down to the character

The hard part is never the change you can see

Comparing two texts is an old, well-understood problem. Every diff tool implements the same family of algorithms, and they all agree about which lines changed when the change is a rewritten sentence. That part is solved.

What is not solved is the other half of the job: the difference you are staring straight at and cannot see. Two lines that are identical to the pixel, and yet something insists they are not the same. A password that will not match. A CSV column that refuses to join. A configuration file that works on one machine and not on another. The lines look equal because, on screen, they are equal — the difference is in characters that were designed not to be drawn.

A tool that marks those two lines as different and stops there has told you nothing you did not already suspect. This one names the character, gives its Unicode code point, and says which side it is on.

Three levels of detail, and why one is never enough

Line comparison is the right level when you want to know the shape of the change: which paragraphs moved, which lines were added, how much of the document survived. It is what version control shows you, and for whole-file work it is the correct answer.

It stops being useful the moment a change is small. A single corrected digit in a long line of numbers, a name spelled differently, a URL with one extra path segment — line comparison paints the whole line and leaves you to find the difference by eye, which is exactly the work you came here to avoid.

Word comparison marks the words that changed inside a changed line. For prose — a contract, a draft, a translation — this is almost always what you want, because it reads the way a person reads: something happened to that word, not to that line.

Character comparison goes inside the word. It is the right answer for a transposed digit, a changed file extension, or a hyphen that turned into an en dash. It is the wrong answer for a rewritten paragraph, where it will happily tell you that the letter "e" survived in fourteen places and produce a rash of coloured fragments that mean nothing.

You can switch between all three without pasting anything again, and switching never changes which lines were paired with which. The pairing is decided once, at the line level, by the comparison algorithm; the setting only changes how finely the marking is drawn inside a line that already changed. That is why moving from words to characters and back never loses your place.

The differences that have no appearance

Trailing whitespace. A line that ends with two spaces looks exactly like a line that does not. It is invisible in every editor that does not deliberately draw it, it survives copy and paste, and it is the single most common cause of "these are the same, why does it say they differ". Here it gets a tinted block at the end of the line and a sentence saying how many spaces there are, on which side.

Non-breaking spaces. Copy text out of a web page, a word processor or a PDF and you will frequently bring back U+00A0 instead of an ordinary space. It renders identically. It is not the same character, it does not match a search for a space, and it will break a lookup, a join or a regular expression without any error message. The comparison names it and outlines it so you can see where it sits.

Zero-width characters. Zero-width spaces, joiners and word joiners have no width at all, so a border around them would be a border around nothing. They are drawn as a marked dot instead — the only honest way to show a character that has no appearance.

Tabs against spaces. An indent made of one tab and an indent made of four spaces can occupy the same width and are not the same text. Both are described in full, rather than reported as "the lines differ".

Line endings are a document-level fact, not a line-level one

Windows ends a line with a carriage return and a line feed. Unix, macOS and Linux use the line feed alone. Convert a file from one to the other and every single line has changed, in bytes, while nothing has changed on screen. It is why a version control system sometimes reports a file as entirely rewritten when nobody touched a word of it.

Flagging that per line would produce a page of identical warnings, so this tool reports it once, at the top: which ending each side uses, and how many lines differ only in that. A file that mixes both — usually the signature of two editors disagreeing — gets its own notice, because mixed endings break tools that a consistent file would not.

A byte order mark and a missing final newline are treated the same way. Both are real differences, both are invisible, and both belong in a summary rather than in the body of the comparison.

Ignoring whitespace without hiding it

Sometimes whitespace genuinely is noise: a file reindented by a formatter, a paragraph rewrapped at a different width. The option to ignore it exists for that. What it does not do is pretend nothing was there. Every line that counts as unchanged only because whitespace was ignored is listed with the exact characters that were set aside.

An ignore option that quietly hides the difference is worse than no option at all, because it turns the one tool that could have found your problem into another tool that says everything is fine.

Text compare side by side, or inline on a phone

Side by side is the better layout when you have the room. Two columns, aligned line for line, with the empty side of an added or removed line drawn as hatching rather than left blank — so you can see that there is deliberately nothing there.

Below roughly 760 pixels it stops working. Two columns of monospaced text on a phone are two columns of about fifteen characters each, which is not a comparison, it is a puzzle. At that width the layout switches to inline: one column, each changed line shown twice, the original marked with a minus and the replacement with a plus, in the order they appear.

The switch happens on its own, and you can override it in either direction. An automatic choice should be a shortcut, not a ceiling — if you want side by side on a phone and are willing to scroll, that is your decision to make.

Large files

The comparison runs on the whole text, not on a preview of it, and long comparisons draw only the rows currently on screen while holding the space above and below open so the scrollbar stays honest about how much is left. A document of tens of thousands of lines behaves like a short one.

There is one honest limit. When two texts have essentially nothing in common, pairing their lines produces coincidences rather than meaning — the algorithm finds that a stray "the" on line 40 matches a "the" on line 900 and builds an alignment out of accidents. Past a threshold the tool stops trying and says so, showing the differing part as one block replaced by another. An invented pairing that looks authoritative is worse than an admission that the two texts are simply different.

Nothing is uploaded

The comparison runs in this browser tab. No text is transmitted, there is no server involved, and you can confirm that by opening your browser's Network tab before you paste — there will be no request, because there is nothing to send it to.

That matters more here than for most tools. The two texts people compare are usually contract drafts, source code, exported credentials, configuration files and unpublished writing. Those are exactly the documents that should not be pasted into a box on somebody else's server in order to find a trailing space.