How to Compare Two Texts and See Exactly What Changed

You have two versions of the same thing — a document before and after edits, two config files, a colleague’s rewrite of your paragraph — and you need to know exactly what changed. Reading both side by side is slow and error-prone. A diff does it instantly.

What a one-word change actually looks like. We gave our text diff tool two versions of the same two lines, differing only in the final word — dog versus cat. The output keeps the quick brown fox as an unmarked shared line, then shows the changed line twice: once marked − (removed) and once + (added). That is the important thing to understand about diffs: they do not report “one word changed”. A line is the unit, so a single character edit still shows up as a whole line deleted and a whole line inserted. That is why reformatting a file makes a diff useless even when nothing meaningful changed.

The actual output, not a description of it. Two versions of the same two lines, differing only in the last word, through our text diff tool:

the quick brown fox
−
jumps over the lazy dog
+
jumps over the lazy cat

The shared line is unmarked; the changed line appears twice, once − and once +. That is the thing to internalise about diffs: the unit is the line, so a one-character edit still deletes a whole line and inserts a whole line. It is also why reformatting a file destroys a diff even when nothing meaningful changed.

What a diff actually does

A diff algorithm finds the smallest set of additions and deletions that turns one text into the other, then shows them in color: green for added, red for removed, plain for unchanged. It’s the same technology behind “track changes” and every code review you’ve ever seen.

Line diff vs word diff

There are two useful granularities:

• Line diff compares whole lines. Perfect for code, config files, CSV and lists, where a “change” usually means a whole line was added, removed or replaced.
• Word diff compares word by word. Perfect for prose, where you want to see that only one word in a sentence changed rather than the whole line lighting up red-and-green.

Start with line diff; switch to word diff when a line shows as changed but you can’t spot what’s different.

The granularity question has a measurable answer in our own output. Two versions differing in one word produced three lines, not one: the shared line unmarked, then the changed line twice — once −, once +. A line diff cannot say “one word changed” because the line is its unit. That is why reformatting a file — rewrapping, reindenting — destroys a diff even when the meaning is identical.

Reading the result

• A red line followed by a green line = that line was edited (removed, then re-added in its new form).
• A lone green line = added.
• A lone red line = deleted.
• The summary (e.g. +3 −1) tells you the scale of the change at a glance.

Reading it is then mechanical: anything unmarked survived, − left, + arrived. Our run gave exactly the quick brown fox / − / jumps over the lazy dog / + / jumps over the lazy cat — and notice the removed and added lines sit adjacent, which is the visual cue that a line was changed rather than genuinely deleted or inserted.

Here is what our own text diff returned for a one-word change — two versions of the same two lines, differing only in the final word:

the quick brown fox
−
jumps over the lazy dog
+
jumps over the lazy cat

Three lines came back, not one. The shared line is unmarked, then the changed line appears twice: once under −, once under +. A line diff cannot report “one word changed”, because the line is its unit of comparison.

Why compare in the browser

Diffs often involve sensitive material — contracts, credentials in a config file, unreleased copy. An online tool that uploads your text is a needless risk. The text diff tool compares entirely in your browser: neither version leaves your device.

A third granularity: character diff

For very short, dense strings, even a word diff is too coarse. A character diff compares letter by letter, which is what you want when a single character is the whole story — a transposed digit in an order number, one wrong character in a hash or API key, or a typo buried inside a long token. Where a word diff marks the entire token as changed, a character diff points straight at the character that differs.

Rule of thumb: line diff for files and lists, word diff for prose, character diff for codes and identifiers.

That unit is also why reformatting destroys a diff. We fed the tool the same three words twice, once on a single line and once on three, changing nothing about the content:

−
one two three
+
one
+
two
+
three

Every line is marked. Nothing was edited — only rewrapped. A word diff or a character diff would report no change at all here, which is the granularity argument settled by one measurement rather than by argument.

When you’ll reach for a diff

• Reviewing an edit — see exactly what a colleague, an editor, or an AI rewrite changed in your draft.
• Comparing versions — a contract, a set of terms, or a config file before and after a change.
• Verifying a copy — confirm two exports, two translations, or two lists really match, character for character.
• Chasing a near-duplicate — two blocks that look identical but produce different results.

Common misunderstandings

• A diff doesn’t track “moved” text. Cut a paragraph and paste it lower down, and most tools show one deletion plus one addition, not a move.
• A whole highlighted line doesn’t mean everything changed. In line mode, changing one word flags the entire line — drop to word or character diff to see the real edit.
• Invisible characters still count. Two lines that look the same can differ by a trailing space, a tab, or a line ending; that’s a genuine difference, not a glitch — which is exactly what the tidy-up in the guide to removing line breaks and duplicate lines prevents.

One more distinction the markers make visible. An insertion returns

alpha
+
beta
 
gamma

while a deletion returns

alpha
−
beta
 
gamma

A true insert or delete has exactly one marked line; a change produces an adjacent −/+ pair. That adjacency is the first thing people learn to read, and it explains why moved code looks so noisy in review — a move is a deletion and an insertion, far apart, with nothing to pair them up.

Tip: normalize first for a cleaner diff

If two files differ only in trailing spaces, tabs or line endings, the diff will be noisy. Run both through the text cleaner first — trim lines and standardize spacing — and the real differences stand out.