To compare two texts, paste the old version and the new one into a diff tool: it lines the two up and marks every line as unchanged, removed or added, with the changed words inside a line shaded. Comparing them in the browser takes about ten seconds. The part worth knowing is where the alignment goes wrong, because a diff compares characters, not meaning, and it will cheerfully report that two lines you cannot tell apart are different.
How to run the comparison
Old version in the top box, new version in the bottom one. There is no file picker, so a file has to be opened in an editor and its contents pasted across. The comparison runs a fraction of a second after you stop typing, and four counters appear under the result heading: added lines, removed lines, unchanged lines, and a similarity percentage. Below those is the aligned text, with removals on a red background and additions on a green one.
Hide unchanged lines earns its checkbox immediately. It collapses everything except the changes and three lines of context on each side, which is the difference between reading a diff of a 900-line document and scrolling through it. The Swap sides button fixes the very common mistake of pasting the versions in the wrong order, which turns every addition into a deletion and makes the whole thing read backwards.
The three ignore options — case, leading and trailing spaces, blank lines — silence differences you have already decided do not count. Turn them on deliberately: each one hides real changes along with the noise.
Why a diff has to guess at all
The obvious approach is to walk both texts in step and flag every position where they disagree. It breaks on the first insertion. Add one line at the top and every remaining line now sits one position lower than its twin, so the comparison reports the entire document as rewritten. Technically correct, completely useless.
So a real diff solves a harder problem first: find the longest sequence of lines that appears, in the same order, in both texts. That is the longest common subsequence. Everything outside it is a deletion on the left or an insertion on the right, and the familiar red-and-green layout falls out of that result.
Finding it costs work. The textbook method fills a grid with one cell per pair of lines, so a 2,000-line document compared against another 2,000-line document means four million cells. Git's default is Myers' algorithm instead — Eugene Myers, "An O(ND) Difference Algorithm and Its Variations", 1986 — whose cost grows with the number of differences rather than with the product of the two file sizes. That is why git diff is instant on a repository where you changed three lines.
The tool here uses the grid, with one shortcut that does most of the work: identical lines at the very beginning and the very end are matched off before the grid is built, and in normal use that removes most of the text. Past roughly 1,500 differing lines on each side it stops trying to align them and reports the whole middle as removed and then re-added, with a note under the buttons saying so. At that point you want a desktop merge tool.
Why two identical-looking lines are marked as different
Because they are not identical. Something in there has no visible shape:
- A trailing space, invisible by definition, usually left by a text editor or a copy-paste.
- A tab where the other side has spaces. Same width on screen, different bytes.
- A non-breaking space instead of a normal one, which is what you get pasting from a web page or a word processor.
- Curly quotes and dashes. Autocorrect turns a straight apostrophe into a typographic one and nothing about the rendering announces it.
- Lookalike letters. A Cyrillic "а" is a different character from a Latin "a" and renders the same in most fonts.
Line endings are the one case you do not have to think about: Windows terminates lines with a carriage return plus a line feed and everything else uses a line feed alone, and the tool normalises both before comparing, so a file pasted from a Windows editor does not show up as 100% different for that reason alone.
For the rest, "ignore leading and trailing spaces" rules out the first cause in one click — but it also hides indentation changes, and in Python, YAML or a Makefile the indentation is the change you were hunting for. When a line is flagged and you still cannot see why after that, the difference is inside the line, and the invisible characters that break text covers how to find which one.
How do you compare text with no line breaks?
You give it line breaks first. A line-based diff has nothing to say about a document that is one long line: change a character in the middle of minified JSON and the result is "1 removed, 1 added" with the entire blob shaded, which tells you nothing you did not already know.
For JSON, XML or minified JavaScript, pretty-print both sides before comparing. Running each version through a JSON formatter puts every key on its own line, and the diff then points at the three fields that actually changed instead of the whole object. The indentation has to match on both sides, so use the same setting twice — otherwise every line differs. Formatting and reading minified JSON goes through the rest of that.
For prose, the equivalent trick is to break each sentence onto its own line in both versions before you paste them. A diff of two chapters where each paragraph is a single line will mark a paragraph as changed when you fixed one comma in it. Word-level highlighting softens this, but sentence-per-line is what makes the output readable.
Comparing two lists that are in a different order
Sort both sides the same way first, then diff. A diff cares about order, so two exports of the same 400 records in different sequences come back as almost entirely changed even though the contents match. Sorting collapses that to the genuine additions and removals — which rows are in one file and not the other.
This only works when the order carries no meaning. A ranking, a changelog or a sequence of steps loses the point of itself when sorted. And if either list has repeats, remove them first, or a duplicate on one side alone offsets everything after it.
What the similarity percentage measures
Whole lines, and only whole lines: unchanged lines counted twice, divided by the combined line count of both texts. It is a sanity check — 3% means you probably pasted the wrong thing — and nothing more.
It is unforgiving in a specific way. Change one word in every line and similarity reads 0%, because no line survived intact, even though the texts are 99% the same by any human measure. A low percentage means the lines moved, not that the text is unrecognisable.
What a diff will not catch
- Moved text. A paragraph relocated from the top of a document to the bottom reads as a deletion and an unrelated insertion. Nothing links them.
- Equivalent structures. Two JSON objects with the same fields in a different order are identical to a parser and completely different to a text diff.
- Formatting. Bold, headings, styles and tracked changes in a Word document do not survive being pasted. You are comparing the plain text only.
- Meaning. A renamed variable, a rephrased sentence with the same content, a currency changed from USD to EUR with the same digits — all of that is either over-reported or invisible.
The word-level highlighting has its own caveat. It pairs the first removed line with the first inserted one, the second with the second, purely by position, so rewriting a paragraph and reordering its sentences turns the pairing into noise. The tool refuses to highlight when two paired lines share less than about a third of their characters, which catches the worst of it. When the shading still looks wrong, switch it off and read the lines whole.
Getting the result out
The copy button produces the shape everyone recognises — a leading plus, minus or space on each line — which pastes cleanly into a review comment or a chat message. It copies the whole comparison, including the unchanged lines that were collapsed on screen, so a long document still comes out long. It is not a patch file: no @@ hunk headers, no file names, so patch and git apply reject it. Generate a real one with git diff.
The text diff checker here does all of the above in one page — both boxes, the whitespace and case options, word-level shading, and a similarity figure — without the text leaving your browser, which matters when the two versions are a contract or someone's medical letter. Paste, read, close the tab.
If the diff insists a line changed and you have read it six times without finding the difference, the culprit is almost always a character with no visible form. The invisible characters breaking your text lists the usual suspects and how to get rid of them.
Frequently asked questions
How do I compare two texts for differences?
Paste the original into one box of a diff tool and the new version into the other. The tool aligns the two and marks each line as unchanged, removed or added, shading the individual words that moved inside a changed line. For long documents, turn on the option that hides unchanged lines so only the changes and a few lines of context remain.
Why does a diff say two lines are different when they look the same?
There is an invisible character in one of them. The usual causes are a trailing space, a tab instead of spaces, a non-breaking space pasted from a web page, a curly quote from autocorrect, or a lookalike letter from another alphabet. Turning on "ignore leading and trailing spaces" rules out the first one; the rest need a closer look at the line itself.
Can I compare two Word documents or PDFs?
Only their text, and only by copying it out and pasting it in. Formatting, tracked changes, comments, tables and images are lost in the process, so the comparison covers the words and nothing else. Desktop Word has its own Compare feature on the Review tab that keeps all of that, and it is the better choice for a contract.
Is it safe to paste confidential text into an online diff tool?
It depends entirely on whether the site sends your text to a server. Many do, which means a draft contract or a patient letter ends up in someone else’s logs. Tools that compare in the browser never transmit anything, and you can verify it by disconnecting from the network and checking that the tool still works.
How do I compare two lists that are in a different order?
Sort both lists the same way before comparing them. A diff is order-sensitive, so two exports of the same records in a different sequence come back as almost entirely changed. Once both sides are sorted, the diff shows only the entries that exist in one list and not the other.
Can I use the output of a diff tool as a patch file?
Usually not. A copied diff normally carries the plus and minus prefixes but no hunk headers or file names, so patch and git apply will refuse it. It is meant for pasting into a review comment or a message; use git diff when you need a patch that actually applies.
Last updated September 19, 2026