Text Compare
Paste two versions and see exactly what changed between them, line by line.
What does it mean to compare two texts?
Comparing two texts means lining them up and marking what was added, what was removed and what stayed the same, usually line by line. The result is called a diff. It is the same operation a version control system performs when it shows you what changed in a file.
How it works
The two texts are split into lines and matched by their longest common subsequence: the longest run of lines, not necessarily adjacent, that appears in both in the same order. Those lines are the ones that did not change, and everything between them is an addition or a removal.
That matching is what keeps a diff readable. Comparing line 1 to line 1 and line 2 to line 2 would mark every line after an insertion as changed; matching by subsequence recognises that one line was inserted and the rest simply moved down.
Line endings are normalised first, so a file saved on Windows and the same file saved on Linux compare as identical rather than as every line changed.
What is a text diff
A text diff is a line by line comparison of two versions of the same text, showing which lines were added, which were removed and which are unchanged. It is the tool every version control system is built on: "git diff" and the side by side view in a pull request are this comparison with a interface around it.
What it compares is lines, not meaning. Two texts that say the same thing in different words are entirely different to a diff, and a line that moved from the top of a file to the bottom reads as one removal and one addition rather than as a move. That is a limitation worth knowing before you conclude that a document changed more than it did.
Reading the result
Each line carries its number on both sides. A line present in both keeps a number on the left and on the right; a removed line has only a left number, an added line only a right one. That is what makes the drift visible: when line 40 on the left is line 46 on the right, six lines were inserted above it.
A modified line appears as a removal followed by an addition, and the summary counts it as one of each. This is how every line-based diff behaves, including git: a line is either the same or it is not, and a change is a line that left and a line that arrived.
- Removed in the original, not in the changed version. Marked with a minus.
- Added in the changed version, not in the original. Marked with a plus.
- Unchanged in both, in the same relative order. These are the anchors the comparison is built on.
When to ignore case and whitespace
Two options change what counts as the same line, and they exist because most real comparisons are noisy.
Ignore whitespace trims each line and collapses runs of spaces and tabs inside it, which removes the diff that appears when a file is re-indented, when a formatter switches from tabs to spaces, or when an editor strips trailing whitespace on save. Use it when you want to know whether the logic changed, and turn it off for anything where whitespace is meaningful: Python, YAML, Makefiles, Markdown code blocks.
Ignore case is for comparing data rather than code: two exports of the same list where one system upper-cased the keys, a column of email addresses, a set of tags. Leave it off for source code, where Value and value are two different identifiers.
What this is good for
- Two config files staging against production, or before against after a deploy. This is the comparison that finds the one environment variable nobody meant to change.
- Two API responses run both through a JSON formatter with keys sorted first, then compare. Without sorting, a reordered response produces a diff full of lines that did not actually change.
- Two versions of a document a contract, a policy, a piece of copy someone returned "with a few small edits". The diff is how you find out how small.
- Two lists exports, inventories, subscriber lists. Sort both first and the diff becomes exactly the entries that were added and removed.
- A patch for a ticket the result downloads as a unified diff, the ---/+++ format git and patch use, so it can be attached, pasted into a review, or applied.
Where a line diff is the wrong instrument
A line diff compares lines, which means a single character changed in a long paragraph is reported as the whole paragraph replaced. For prose that is wrapped as one line per paragraph, that is technically correct and practically useless; a word-level diff is what you want there. The usual workaround is to re-wrap both texts one sentence per line before comparing.
It is also the wrong tool for structured data where order does not matter. Two JSON objects with the same fields in a different order are the same object and a completely different text, which is why sorting the keys first is not a nicety but the thing that makes the comparison mean anything. The same applies to CSV rows and to any export whose ordering is incidental.
And it cannot tell you that a block moved. A function relocated from the top of a file to the bottom reads as a large deletion and a large insertion, because by the rules of the algorithm that is exactly what it is.
Comparing things you should not upload
Both texts stay in the page. The comparison runs in your browser, nothing is sent to a server, and the tool keeps working offline, which is the only reason it is reasonable to paste two versions of a contract, a config file holding a connection string, or an export with customer records in it.
Most online diff tools post both texts to a backend to compute the comparison. That is a copy of both documents on someone else’s machine, and for anything under an NDA or subject to the GDPR it is a copy you were probably not allowed to make.
Questions people ask
Are my texts uploaded?
No. The comparison runs in your browser and nothing is sent anywhere, so two versions of a confidential document can be compared safely. The tool works offline.
Why is one changed character reported as a whole changed line?
Because this is a line diff: a line is either identical or it is not. For prose, re-wrap both texts one sentence per line before comparing, or use a word-level diff.
Why does my JSON diff show lines that did not change?
Almost always because the key order differs between the two responses. Format both with keys sorted first and the diff collapses to the fields that genuinely changed.
Does it handle Windows and Unix line endings?
Yes. CRLF and LF are normalised before the comparison, so the same file saved on two systems compares as identical rather than as every line changed.
Can I get a patch out of it?
Yes. The download gives a unified diff, the ---/+++ format git and patch use, so it can be attached to a ticket or pasted into a review.