Diff Checker

How a diff works

A diff answers one question: what is the smallest set of edits that turns the first text into the second? It works by finding the longest common subsequence, the largest set of lines that appear in both texts in the same order. Those lines are unchanged. Every line of the original that is not part of it was removed, and every line of the modified text that is not part of it was added.

This checker uses the algorithm Eugene Myers published in 1986, which is also what git uses by default. It finds a minimal edit script quickly when two texts are mostly the same, because it only explores as far as the number of differences requires. Where a removed line and an added line sit in the same spot and share enough words, they are shown as a single edited line, and the words are diffed a second time to mark exactly what changed inside it.

This is also why the result is better than comparing line 1 to line 1 and line 2 to line 2. Insert one line at the top of a document and a naive comparison reports every line below it as changed. A real diff reports one added line.

Reading the result

• Red lines exist only in the original. Green lines exist only in the modified text. On an edited line, the darker highlight marks the words that differ.
• Line numbers refer to each side separately, so after an insertion the right-hand numbers run ahead of the left.
• Unchanged lines are folded away, keeping three lines of context around each change, the same amount git diff shows. Click a fold, or Show all lines, to expand.
• Side by side is easiest for prose and short edits. Unified stacks the old and new versions of each line and reads better on a phone or for long lines.

The unified diff format

The unified view mirrors the format patches are written in. If someone sends you a patch file, it looks like this:

@@ -12,4 +12,5 @@
 function total(items) {
-  return items.reduce((a, b) => a + b);
+  if (items.length === 0) return 0;
+  return items.reduce((a, b) => a + b, 0);
 }

The header says the hunk starts at line 12 and covers 4 lines in the old file and 5 in the new. Lines starting with a minus were removed, a plus means added, and a space means unchanged context.

Getting a cleaner comparison

• Formatting changes hide real ones. If one version was re-indented or had trailing spaces stripped, turn on Ignore whitespace so only the meaningful edits remain.
• Normalize structured data first. Two JSON files with the same data in a different key order produce a noisy diff. Run both through the JSON formatter with sorted keys, then compare.
• Prose diffs best one sentence per line. A paragraph is one long line, so a single comma marks the whole paragraph as edited. The word highlighting still shows where, but for heavy editing, a line break after each sentence gives a much clearer result.
• Check what you are comparing. Text copied from a PDF often carries hard line breaks at the end of every printed line. Copy both versions the same way so those breaks match.