Diff checker
Compared in your browser · nothing is uploaded
Compares two texts and marks what was added and removed, using a longest-common-subsequence match so a single inserted line shows as one insert rather than shifting the 200 below it. Case and whitespace can be ignored, which is what makes it usable on two lists exported from a spreadsheet.
How to use the diff checker
That distinction is the whole reason a real diff is worth having. Comparing line one to line one, line two to line two and so on means a single inserted line at the top makes every subsequent line appear changed: technically true and completely useless. Finding the longest sequence of lines the two texts genuinely share, and marking only the gaps, is what produces a diff a person can read. Unchanged runs are folded to a marker by default, because a diff of two long documents is mostly unchanged lines and showing all of them buries the three that matter.
The everyday version of this is not two revisions of a document but two lists: two exports, two mailing lists, two inventories, where the question is which rows are missing from one side. Two settings matter more there than in a prose diff. Ignore whitespace catches the trailing spaces that spreadsheet exports leave on values, which otherwise make identical entries look different; ignore case catches email addresses, which most systems treat inconsistently. Sorting both lists before pasting them is the third thing, and it is not a setting: an unsorted comparison faithfully reports reordering as change, which is almost never the question being asked. Line endings at least are not something to think about: a file written on Windows and one written on a Mac split into the same lines here, so the carriage return nobody can see does not mark every row as changed.
The patch is the other reason to use a line diff rather than a prose one. Copy as patch writes the comparison out in unified form: a --- line for the original, a +++ for the changed version, and every line carrying a space, a minus or a plus in front of it. That is also why the boxes are labelled rather than numbered: left is the original, so swapping them inverts the sign of every line in the output. It is written to be read, quoted in a ticket or pasted into a review. A tool that applies patches wants hunk headers with real line numbers on top of that, which two pasted texts with no file behind them cannot honestly supply.
Two limits worth naming. This compares text, so it has no idea what the text means: two JSON documents differing only in the order of their keys fill the result with differences that are not differences, and formatting and sorting both before comparing them is what leaves only the actual change. And the comparison builds a table with one cell per pair of lines, so two thousand lines against two thousand is four million cells, which is the ceiling here. Past it the result falls back to a straight positional comparison and says so on the panel; the way through is to compare the section in question rather than the whole file.
What people use it for
- Seeing what changed between two versions of a file
- Finding which addresses are in one export and not the other
- Reconciling two spreadsheet columns that should hold the same list
- Producing a unified patch from two pasted versions
- Checking a config change before it ships
- Seeing whether two lists differ in content or only in order
Questions
Because an inserted line shifts every line below it. This uses a longest-common-subsequence match, which finds the lines that genuinely correspond.
Yes, both. The output still shows your original text: only the comparison is relaxed.
Almost always trailing whitespace from a spreadsheet export. Turn on ignore whitespace.
Yes. An unsorted comparison treats reordering as a change, which is rarely what you want from a list.
No. A file written on Windows and one written on a Mac split into the same lines, so the invisible carriage return does not mark every row as changed.
Collapse unchanged folds the matching entries away so the differences stand alone. It is on by default.
The comparison in unified form: a --- line, a +++ line, and every line prefixed with a space, a minus or a plus. It has no hunk headers with line numbers, so read it or paste it into a review rather than feeding it to git apply.
Left is the original, right is the changed version. The patch is written in that direction, so swapping the boxes inverts the sign of every line.
Paste the contents. Nothing is read from disk, so both versions have to come in through the boxes.
Not structurally; it compares text. Format and sort both documents first, or differences in key order alone will fill the result.
Two thousand lines against two thousand is four million cells, which is the ceiling. Past it the comparison falls back to a positional one and says so.
The text compare page is the better shape for that: it is built around the word-by-word comparison, where an edit inside a sentence marks the words that changed rather than the whole paragraph.
No. Both lists stay in your browser, which matters when the thing you are comparing is two exports of customer addresses.