Is it a word-level or a line-level comparison?

Line-level first: it finds the lines that were added or removed, and then highlights the phrase-level difference inside each changed line. That is the order a reader wants - what moved, and then what changed in it.

How does it decide which lines are the same?

With a longest-common-subsequence match, which keeps the order of both texts. That is why a paragraph that moved shows up as a move rather than as a delete plus an unrelated add.

How long a text can it handle?

Tens of thousands of lines work fine. Past a very large size the comparison is skipped rather than freezing the page, so on a huge file you get a message instead of a result.

Are the two texts uploaded?

No. The comparison happens in your browser, so neither text is sent anywhere.

Workflows

How to Compare Two Texts and See Exactly What Changed

A text diff is a line-by-line argument about what is the same. Here is how the comparison decides, and the one thing it cannot tell you.

Zahid SheerazOctober 22, 20264 min read

Two versions of the same text, and you need to know what changed between them. A colleague's rewrite of your paragraph. A configuration file before and after an edit. A contract against the version somebody sent you last week. The changes are always small, and they are always exactly the part you need to see.

What a text diff actually does

The Text Diff tool takes two blocks of text and works out the difference between them, line by line, then phrase by phrase inside the lines that changed.

There are two levels, and the order matters:

Line level. The tool finds the lines that are identical, the ones that were removed, and the ones that were added. It does this by working out the longest common subsequence - the longest run of lines that appears in both texts, in the same order.
Phrase level. Inside a line that was removed and a line that was added, the characters that differ are highlighted.

That order is the one you want. "These two lines changed" comes first, and "here is exactly which words in them differ" second. A tool that only did the character level would bury you in noise; a tool that only did the line level would leave you to hunt for the word that changed.

Why the "longest common subsequence" matters

This is the bit of the algorithm that makes the output readable, and it explains the shape of the result.

The longest common subsequence is the longest set of lines that appear in both texts in the same order. Everything else is a removal or an addition.

The practical effect: a block that moved is shown as a move, not as a deletion plus an unrelated insertion. If you moved a paragraph from the end of a document to the middle, the diff shows the paragraph landing in its new place, with the surrounding lines matched up. Without the ordering constraint, every line after the move would be reported as changed.

That is the difference between a diff you can read and a diff that says "everything changed".

What the output looks like

Unchanged lines are shown as they are, so you keep your bearings.
Removed lines are marked as removed.
Added lines are marked as added.
Changed lines are marked as both, with the differing phrase highlighted inside them.

For a document where somebody changed three words in a paragraph of forty, you see one line marked, with three words lit up inside it - not forty lines marked as different.

The one thing it cannot tell you

A diff shows what is different, not what is right.

If a line changed from "the client shall pay within 30 days" to "the client shall pay within 90 days", the diff will highlight 30 and 90 with equal weight. It has no idea which one is correct, which one was authorised, or which one is a mistake. Neither does any diff tool, and a tool that pretended otherwise would be lying to you.

Read the highlighted changes, not just the count of them. The number of changes is a hint; the changes themselves are the answer.

Practical uses

Reviewing a rewrite. Paste the original and the new version, and the diff shows exactly what was touched - including the small change nobody mentioned in the summary.
Comparing configurations. A settings file before and after an edit, where the one line that changed is the one that broke it.
Checking a translation against the original. The line structure stays put and the words change, so the diff reads as a phrase-level edit rather than a wall of red.
Two versions of a contract. See what was altered between the draft and the copy you are about to sign.

That last one is worth doing properly. A diff makes an unauthorised change visible in a way that reading both versions side by side does not.

What it does not do

It does not ignore whitespace. A line that differs only by a trailing space is a different line. That is usually what you want, and occasionally not.
It does not ignore case. Apple and apple are different lines. A case-insensitive diff would hide real changes.
It does not do anything clever with meaning. It compares characters. "Colour" and "color" are two different words to it.
It does not merge or fix anything. It shows; you decide.

A short checklist

Paste the OLD text on the left and the NEW on the right. It works either way round, but the conventional order reads better.
Look at the changed lines first, then the phrase highlights inside them.
A moved paragraph shows as a move - that is the algorithm working, not a bug.
Read the changes, do not just count them. The tool cannot tell you which side is right.
Whitespace and case count as differences. That is usually correct.
Very large files are skipped rather than frozen. The comparison is local, so nothing is uploaded.