Text Tools · runs in your browser

Text Compare & Diff

Compare two blocks of text and highlight exactly what changed.

No sign-up No file limit Nothing uploaded

Text Compare & Diff

How to use 3 steps
  1. Paste the Original and the Changed text.
  2. Choose Compare by and the View, plus the ignore options.
  3. Press Compare and read the highlighted changes.
Differences

Differences are found with a longest-common-subsequence pass, the same approach diff uses, so unchanged text is matched as a block rather than character by character.

How this tool works

The two texts are split into tokens — lines, words or single characters — and compared by finding the longest sequence that appears in both, in the same order. Everything outside that sequence is an addition or a removal. This is how version-control tools compare files, and it is what makes the result readable: matching blocks stay put instead of every line after an inserted one being reported as changed.

Matching runs at the start and end of both texts are recognised and set aside before the comparison table is built, which on real documents removes most of the work, since edits are usually confined to part of a file. Ignoring case or surrounding whitespace changes what counts as a match; the text shown to you is always the original, so an ignored difference simply stops being highlighted rather than being rewritten.

Reading the comparison

  • An edited line is a removal plus an addition: at line granularity there is no concept of a modified line — the old one goes and the new one arrives. Switch to word granularity to see what actually changed inside it.
  • The counts are tokens, not edits: at word granularity a rewritten sentence can report a dozen additions. Compare the counts between runs rather than reading them as a number of changes.
  • Granularity is the main setting: lines for code and structured text, words for prose, characters for short strings where you are hunting a single wrong digit.
  • Character granularity is the expensive one: the comparison cost grows with the product of the two lengths, so a long document compared character by character will take noticeably longer than the same document compared by line.

An edited line is a removal and an addition

The comparison works line by line. When a line changes, it 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 [msm_tool slug="text-diff"] works this way, and knowing it stops the numbers being alarming.

Whitespace counts

Two lines that look identical differ if one has a trailing space, or if one uses tabs where the other uses spaces. The comparison is exact.

This is the most common source of "these are the same, why is it showing a difference". Trailing whitespace is invisible in most editors, and it is the usual culprit. If a diff shows changes you cannot see, that is what to look for first.

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.

If an entire document reports as changed and you know it has not been, check the line endings before checking anything else.

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 a line-based comparison 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, handles renames, and can show word-level changes within a line.

For prose where you want to see which words changed rather than which lines, a word-level comparison is far more readable. A line-based diff of a rewritten paragraph tells you the paragraph changed, which you knew.

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.

Frequently Asked Questions

Specific to the Text Compare & Diff. Broader questions about this category are answered on the category page.

Line comparison has no modified state — the old line is a removal and the new one an addition. Word granularity shows the change within the line.
Words. Line comparison marks a whole paragraph as changed when one word moved, and character comparison is noisier than it is useful.
No. They only affect what counts as a match. What is displayed is always exactly what you pasted.
Its cost grows with the two lengths multiplied together. Comparing by line first and drilling into the changed part is much faster.
The texts differ, but only in ways you asked to ignore — case, or surrounding whitespace. Untick those options to see the differences.

Subscribe to receive notifications about new tools, features, and productivity tips.