EveryToolAI
Index

Text Diff Checker

This diff checker compares two blocks of text and shows exactly what changed — added lines in green, removed in red, unchanged in grey — updating as you type. It works on whole lines, which is how people read changes to prose and code alike. Both texts stay in your browser, so contracts, drafts and private notes are safe to paste.

updated

Differences (2 changed lines)
The quick brown fox
jumps over the lazy dog
+ leaps over the lazy dog

How the comparison works

The two texts are compared line by line using a standard diffing algorithm — the same family of algorithm that powers version control. It finds the longest sequence of lines common to both versions, and everything outside that sequence is what changed.

That framing matters because it explains the output. A diff does not detect edits; it detects insertions and deletions. When you change a word in the middle of a sentence, the algorithm reports the old line as removed and the new line as added, because from its point of view that is what happened. Nothing was tracked from one to the other.

Working on whole lines rather than characters is a deliberate trade. It matches how people read changes — you scan for which paragraphs or statements moved — and it keeps the output readable on large inputs. The cost is that a single changed character marks the entire line, so prose written as one long paragraph per line will report the whole paragraph as changed. Adding line breaks at sentence boundaries makes diffs of prose dramatically more useful, which is why technical writers do it.

A worked example

Two versions of the same short text, and what the comparison reports:

One word changed on the second line
  the quick brown fox            unchanged
- jumps over the lazy dog        removed
+ leaps over the lazy dog        added
  and then goes home             unchanged

One word changed, and the line is reported as removed and re-added. That is not the tool being unhelpful — it is what line-level comparison means, and it is the same thing your version control shows.

Moved blocks are worth understanding too. A paragraph relocated from the top of a document to the bottom appears as a deletion in one place and an addition in another, because a line diff has no concept of a move. If a comparison looks alarmingly large after a reorganisation, this is usually why, and it is not a sign that anything was rewritten.

The count of differing lines is therefore a measure of textual churn rather than of how much the meaning changed. A find-and-replace across a document produces a huge diff and may change nothing important; a single altered number in a contract produces one line and may change everything. Read the diff, do not weigh it.

What people actually diff, and why that is the whole argument

Think about the two things you are pasting in. They are two versions of something that matters enough to check carefully — which is a very specific category of document.

In practice it is contract language before and after the other side's edits. A policy document in review. Two versions of a configuration file, one of them the production one. A press release under embargo. Meeting notes. Legal correspondence. Source code that has not been released. People do not carefully diff things that are already public.

Most online diff tools post both texts to a server to compare them there. So the moment you check what the other side changed in a contract, you have uploaded both the original and their proposed version to a third party — often, ironically, while doing the diligence that the contract itself requires of you.

Here the comparison runs in your tab and neither text is transmitted. The check is the same one that works anywhere: open the Network tab and paste something, or disconnect from Wi-Fi and diff anyway. Nothing is sent, because there is nothing on the other end to send it to.

Where a line diff is the wrong tool

Whitespace counts. A line with a trailing space differs from one without, and a file converted between Windows and Unix line endings can appear entirely rewritten when nothing visible changed. If a diff shows every line as modified for no apparent reason, line endings are the first thing to check.

Reformatting defeats it. Running a code formatter, re-wrapping a paragraph, or changing indentation will mark large regions as changed even though the meaning is identical, because every affected line is textually different. There is no way for a line-based comparison to see through that.

Structured data compares poorly this way. Two JSON documents with identical content but different key ordering or indentation will diff as completely different. Format both consistently first — the JSON formatter linked below will do it — and then compare, which turns a meaningless diff into a meaningful one.

And it says nothing about meaning. A diff shows that a clause changed, not whether the change matters. It is a tool for finding what to read, not a substitute for reading it.

Frequently asked questions

How does the diff work?

It compares the two texts line by line with a standard diffing algorithm, finding the longest sequence of lines common to both and marking everything else as added or removed. Green lines exist only in the new text, red only in the original.

Why is a whole line marked as changed when I only edited one word?

Because the comparison works on whole lines. A diff detects insertions and deletions rather than edits, so a modified line is reported as the old line removed and the new one added. Breaking prose at sentence boundaries rather than writing one long line makes diffs far more readable.

Can I compare code as well as prose?

Yes. The comparison is plain-text and line-based, so it works equally well for source code, config files, CSV data and written text. Just be aware that running a formatter over one side will mark large regions as changed even though nothing meaningful differs.

Why does everything show as changed?

Usually line endings. A file saved on Windows and one saved on Unix differ on every line invisibly, so the comparison reports the whole document. Trailing whitespace does the same on individual lines. Normalise both texts and compare again.

How should I diff two JSON files?

Format both the same way first, then compare. Two JSON documents with identical content but different indentation or key order will otherwise diff as entirely different, because a line comparison cannot see the structure underneath. The JSON formatter linked below will normalise them.

Is my text uploaded anywhere?

No. Both texts are compared entirely in your browser and never sent to a server — which matters, because the things people carefully diff are contracts, policy documents, unreleased code and correspondence. Disconnect from the internet after the page loads and it still works.

Related tools