An edited line is a removal and an addition
Compared line by line, a changed line is not reported as “modified” — it appears as the old line removed and the new line added, adjacent to each other.
That is how nearly every diff works, and it explains the counts. Change one word in one line and the summary says one removal and one addition, not one change. A file where you altered a comma on every line will report as entirely rewritten.
The Text Compare & Diff can also compare by word or by character. The same edit then shows as just the words or letters that changed, and the counts are counts of those instead of lines. Knowing which unit you are counting stops the numbers being alarming.
Whitespace, and the option that hides it
Leading and trailing whitespace is ignored by default, so a trailing space or an indent made of tabs instead of spaces does not count as a change. Untick that option and the comparison becomes exact: two lines that look identical then differ if one has a trailing space.
Invisible whitespace is the most common source of “these are the same, why is it showing a difference”. If an exact comparison shows changes you cannot see, that is what to look for first. Spaces in the middle of a line always count.
Line endings are the other invisible difference
Windows ends lines with a carriage return and a line feed; Unix and macOS use a line feed alone. A file that has travelled between the two can differ on every single line while looking identical.
Comparing by line evens this out: both kinds of line ending are treated as the same before anything is compared. Comparing by character does not, because each carriage return is a character of its own — so if a character comparison reports a change at the end of every line, compare by line instead.
Reordering is not detected as reordering
Move a paragraph from the top of a document to the bottom, and the diff reports it as removed from one place and added in another. It has no concept of a block having moved.
That is correct behaviour for this kind of comparison, whichever unit it counts in, and it makes large reorganisations hard to read. For those, comparing section by section is usually more informative than comparing the whole document.
What it is genuinely good at
- Verifying a small edit. Confirming that a change to a config file, a contract or a translation touched only what you intended.
- Comparing two versions someone sent you without version control — two Word exports, two email drafts, two vendor quotes.
- Checking a copy-paste survived. Whether the text in the CMS matches the text that was approved.
- Finding an unintended change. The diff you run because something broke and you want to know what moved.
What to use instead, when
For code under version control, your version control system’s diff is better — it knows the history and handles renamed files.
For prose, compare by word rather than by line. A line-based diff of a rewritten paragraph tells you the paragraph changed, which you knew; a word-based one shows which words did.
For structured data — JSON, YAML, configuration — a structural comparison is better again, because it ignores formatting and key order and reports what actually differs.
Nothing is uploaded
Both texts are compared in your browser, which is worth knowing when the documents are a contract, an unreleased announcement, or anything else you would rather not paste into a service.