Compare two texts

How to use it#

1. Paste the original version into the first box, or drop its file on the box. Open file does the same from a file picker.
2. Paste or drop the version you want to compare into the second box.
3. Tick ignore case or ignore whitespace if those differences do not matter to you.
4. Switch the view between stacked and side by side, whichever reads better.
5. Read the result, or copy it as a patch to paste into a review.

How the lines are matched up#

The hard part of comparing two texts is not spotting that they differ. It is working out which line in the second text corresponds to which line in the first, because once one line is inserted near the top, every line below it has shifted and a naive comparison reports the entire rest of the file as changed.

The answer is to find the longest sequence of lines that appears in both texts in the same order, and treat those as the unchanged ones. Everything else is then either a line the original had and the new version does not, or the other way round. A line that was edited shows up as both: the old wording marked as removed, the new wording marked as added directly underneath.

Identical stretches at the top and bottom are matched before any of that work begins, which is why comparing two copies of a long document with one paragraph changed is instant.

When to ignore case and whitespace#

Trailing spaces are the classic false positive. An editor that strips them on save will mark every line it touched as changed, burying the two lines you actually care about. Ignore whitespace treats a line as the same when only its spacing differs, including runs of spaces between words, so reindented code compares on its content.

Both options change the comparison and not the text. The lines are still shown exactly as you pasted them, so you can see that the spacing differs while the tool agrees the meaning has not. That distinction matters when the whitespace turns out to be the bug.

Reading the result#

Stacked puts everything in one column, with a removed line directly above the line that replaced it. Each row carries two line numbers, one for its position in the original and one for its position in the changed version. An added line has no number on the left because it did not exist there, and a removed line has none on the right.

Side by side gives each version its own column, with a line sitting opposite its counterpart. Where one version has a line the other does not, the empty cell is hatched, which is how an outright addition is told apart from an edit. This view suits a change with a lot of rewritten lines, because you read across rather than down.

In the stacked view the colour is backed by a marker in its own column, a plus or a minus, so the result still reads if colours are hard to tell apart or the page is printed in black and white. Side by side puts that information in the position instead: left is what you had, right is what you have now.

Within a line that was edited, the characters that differ carry a stronger wash of the same colour. A version number that went from 1.4.0 to 2.0.0 marks the two digits that moved rather than the whole line, which is the difference between reading a diff and searching one.

Copy patch gives you the same comparison in the format a patch file uses, with a leading plus, minus, or space on each line, whichever view is on screen. It pastes into a code review or an issue and stays readable there.

What it compares, and what it does not#

Lines are the unit. Change one word in a long paragraph and that whole paragraph counts as a line removed and a line added, because as far as the alignment is concerned the line differs. Within such a pair the characters that actually changed are then marked, so you are not left comparing two near-identical paragraphs by eye.

That suits code, configuration, logs, and CSV, where a line is a unit of meaning. For prose kept as one line per paragraph the line counts are coarse, though the character marks still point at the edit.

Windows, Unix, and old Mac line endings are all read as line breaks, so a file saved on one platform compares cleanly against the same file saved on another without every line coming back changed.

A file dropped on a box is read as text. UTF-8 is tried first, a byte order mark is honoured and then set aside, and a file that is not valid UTF-8 is read as Windows-1252, the older encoding such files usually use. When a file is read as anything other than UTF-8, the line under the box says which encoding was used. Word documents, PDFs, and spreadsheets are not plain text, so copy the text out of them and paste it instead.