Compare Two Texts
Paste two versions of anything — a contract, an email draft, a config file — and see exactly which lines were added, removed, or left alone. The comparison uses the same longest-common-subsequence approach that version control systems are built on. Unpublished documents deserve caution, which is why nothing pasted here is ever stored — both texts are compared and discarded per request.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeWhat it does
- Line-by-line comparison with added and removed lines highlighted
- Ignore case and ignore leading/trailing whitespace options
- Copies a classic unified-style diff with +/− prefixes
- Handles large documents by peeling the unchanged beginning and end
How to use Text Diff
- 1
Paste both versions
The older text goes on the left, the newer on the right. Order matters only for the labels — swapping the sides swaps which lines count as added and which as removed.
- 2
Choose what to ignore
Turn on the whitespace option when one version was re-indented, and ignore case when capitalisation changes are noise rather than edits you care about.
- 3
Read the highlights
Red lines with a minus exist only in the original; green lines with a plus exist only in the changed version. Unmarked lines are common to both.
- 4
Copy the diff
The copy button produces plain text with two-character prefixes — the format code reviewers already know how to read — ready for an email or a ticket.
How it works
The two texts are split into lines, and the tool computes their longest common subsequence — the largest set of lines that appear in both versions in the same order. Everything in the original that is not part of that subsequence is a removal; everything in the changed version that is not part of it is an addition.
Before the real work starts, the common beginning and end of the two texts are peeled off and passed straight through. This matters more than it sounds: comparing every line against every other line grows quadratically, but real edits are local. Two thousand-line documents that differ in one paragraph reduce to a comparison a few lines wide, which is why the result appears instantly.
When the algorithm faces a tie — an addition or a removal would both be minimal — it emits the removal first. That ordering is a convention, not a correctness matter, and it is the convention every code-review tool follows.
Reading the result
A diff shows the smallest set of line edits, which is not always the story of what the author did. The second example above demonstrates the classic case: a paragraph moved elsewhere appears as an independent removal and addition, because "moved" is not a concept the model can express. Similarly, if you rewrap a paragraph to a different line width, every line boundary shifts and the diff reports the whole paragraph as changed — turning on the whitespace option does not rescue this, because the line contents genuinely differ.
The practical advice: diff prose paragraph by paragraph, and diff structured text (lists, configs, code) exactly as it is.
When you'd use this
Checking what a colleague actually changed in the contract they sent back. Verifying that two exports which should be identical actually are — the Unchanged count equalling the line count is a one-glance answer. Reviewing a config file against the version that last worked. Confirming that an edit you made in one place did not silently touch anything else.
A moved paragraph reads as a deletion and an addition
Line comparison has no concept of movement, and this is the limitation that matters most when reviewing prose.
Cut a paragraph from the top of a document and paste it at the bottom, and the diff reports it removed from one place and added in another. Nothing has actually changed about the text, but the summary counts it twice and a reader scanning the output has to notice that the removed lines and the added lines are the same lines.
Reordered sections in a contract, a reshuffled configuration file, a list sorted differently — all produce large diffs describing no real edit. It is worth checking for before concluding that a document was heavily rewritten.
The related case is a change of wrapping. If one version wraps at 72 characters and the other does not, every line differs even when every word is identical. A diff that reports one hundred percent changed usually means the two files are formatted differently rather than written differently. Running both through the line-break tool first, so they wrap the same way, turns that into a diff of the actual words.
Whitespace does the same on a smaller scale: an editor converting tabs to spaces, or trailing spaces stripped on save, marks lines changed that read identically. The whitespace remover normalizes both sides before comparison.
Identical output is evidence, missing output is not
The count of unchanged lines is the most useful number here, and it is worth being precise about what it proves.
If every line is unchanged, the two texts are byte-identical in their line content, and that is a genuine verification — a good way to confirm that a file survived a transfer, or that two exports of the same data really match.
What it does not prove is that nothing is missing. A diff compares what you gave it. If one version was truncated during copying — a common way a long document loses its last page — the tool reports the shortfall as deleted lines at the end, which is correct and easy to skim past when you are looking for edits in the middle.
So check the line counts on both sides before reading the diff. Two documents that should be the same length and are not is a different problem from an edit, and it usually means something went wrong with the copy rather than with the content.
Examples
A changed time and an added instruction
The edited first line appears twice — once as a removal and once as an addition — because a line diff has no concept of a partial edit. Reading a minus/plus pair as "this line changed" is the one habit that makes diffs easy to scan.
A moved line is not detected as a move
Moving "alpha" to the end reads as one removal plus one addition. The algorithm keeps the longest run it can — beta and gamma — and everything else must be expressed as edits. No mainstream diff detects moves; this one is honest about it rather than pretending.
Frequently asked questions
Why does an edited line show up as removed and added?
Because the comparison works on whole lines, and an edited line matches neither version exactly. The algorithm sees the old line disappear and a new one appear in its place. That sounds crude, but it is how git and every mainstream review tool present changes too — the minus/plus pair is the standard notation for "this line was modified".
Will the result match what git diff shows?
Usually, but not always line for line. Both tools find a minimal set of edits, and when several minimal answers exist they can pick different ones — git uses a variant of Myers' algorithm with its own tie-breaking heuristics. Neither output is wrong; they are different shortest paths between the same two texts.
Is there a size limit?
A generous one. The unchanged beginning and end of both texts are peeled off first, so what counts is the size of the changed region, not the documents. If that region still needs more than a few million comparisons, the comparison is refused outright with a clear message asking you to compare smaller sections, rather than running away.
Can I compare confidential documents here?
The comparison runs on this site's own server, so both texts are sent over an encrypted connection to be compared — but nothing is written to disk, logged, or retrievable afterward. They exist only for the moment it takes to compute the diff, then the request ends and both are gone. Whether a specific document is yours to paste anywhere is governed by your own confidentiality obligations, not by the tool.
What exactly do the ignore options change?
They change how lines are compared, never how they are displayed. With whitespace ignored, " total = 4" and "total = 4" count as the same line; with case ignored, "Invoice" equals "invoice". The output always shows the original spelling from whichever side the line came from, so normalization never rewrites your text.
Further reading
- The Invisible Characters That Break Your SpreadsheetTwo cells look identical, and the lookup returns nothing. A search for a name that is visibly right on screen finds no match. Both have the same cause: a character with no width sitting inside the text, put there by a word processor or a web page, doing nothing except making two strings unequal.
- Windows Line Endings Cost 1.8% on Disk and Three Bytes CompressedEvery line of a Windows text file ends with two characters where a Unix one ends with one. It is the oldest formatting difference in computing and it is worth a measurement, because the size argument turns out to be the least important thing about it.
- Two Words That Look Identical and Are Not the Same TextA search that finds nothing, a duplicate that will not deduplicate, a login that fails with the right password. Often the cause is that two pieces of text that look exactly the same on screen are different sequences of bytes — and Unicode allows both spellings on purpose. Here is what is happening and the one-line fix.