Diff Checker

A diff checker compares two versions of text or code and shows what changed: which lines were added, which were removed, and which are the same in both. It is the same idea as git diff or the file view in a pull request, applied to two blocks of text you paste in yourself.

The value is in what it removes. Reading two versions side by side and spotting the differences by eye is slow, and it is unreliable in exactly the case that matters — a single changed character in the middle of a file that otherwise looks identical.

1Original                    Modified2─────────────────────────────────────────────────3const name = "John";        const name = "John";4const age = 30;             const age = 31;5console.log(name);          console.log(name);6 7→  1 addition, 1 deletion, 1 changed section

The pipeline is short and the interesting part is the middle step.

1Original ──┐2           ├──▶  split into lines  ──▶  find the longest3Modified ──┘                            common subsequence4                                                │5                                                ▼6                            in both  ──▶  unchanged7                            left only ──▶  removed  (−)8                            right only ──▶ added    (+)

Both versions are split into lines, and the algorithm finds the longest sequence of lines that appears in both, in order. Whatever is in that sequence is unchanged. Whatever is left over on the left was removed; whatever is left over on the right was added. There is no third category — a “modified” line is a removal and an addition that happen to sit next to each other, which is why a patch file contains both.

This tool uses Myers’ algorithm, published in 1986 and the default in git. Its useful property is that its cost scales with the number of differences rather than with the size of the input, so two large files that differ by three lines compare almost instantly. Two files with nothing in common are the expensive case, and there the tool stops trying to align them and says so.

One consequence worth knowing: a diff is not unique. Several different edit scripts can turn one file into another, and the algorithm picks a shortest one. When a change is genuinely ambiguous — a repeated line, a moved block — different tools can legitimately show it differently.

The same comparison, presented two ways. Neither is more accurate; they suit different questions.

Side by side

Two columns, original on the left and modified on the right, aligned so corresponding lines sit opposite each other. Best when lines were rewritten, because you can read both versions of the same line at once. It needs width, which is why the tool above switches to tabs on a phone rather than squeezing two columns into a screen neither fits.

Unified

One column, with removals and additions interleaved and marked - and +. It is the format git diff, diff -u and patch files use, so it is what to copy when the diff is going somewhere else.

1--- original          ← the two files2+++ modified3@@ -1,4 +1,4 @@       ← where this hunk sits in each4 const name = "John";  ← context: unchanged, one space5-const age = 30;       ← removed from the original6+const age = 31;       ← added in the modified7 console.log(name);

The @@ header is what makes a unified diff applicable rather than merely readable: it tells patch which lines of which file the hunk belongs to. The unified view here emits real headers, so what you copy can be fed to git apply.

One caveat: if you have turned on an ignore option, the diff describes a normalised comparison, and the hunks may not apply cleanly to the literal file.

Underneath they are the same operation. A line comparison does not know or care whether a line is a sentence or a function signature, which is why one tool can handle prose, source code, CSV, YAML and log files without a mode switch.

What differs is which settings suit which material.

• Code wants line granularity and strict whitespace. A line is a meaningful unit, and indentation is significant in Python, YAML and Makefiles. Leave the ignore options off unless you have a specific reason.
• Prose often wants word granularity. Paragraphs are long lines, so a reworded sentence turns the whole line red and green at line granularity. Word granularity highlights the words that actually moved.
• Generated output often wants ignore options. Comparing a build artefact against a committed one, trailing whitespace and blank-line differences are usually noise from the generator rather than real changes. When the two sides came out of different tools, the JavaScript formatter or the CSS formatter will put both into one shape first, so the diff shows changes rather than style.

Syntax highlighting affects the editors only. It never changes what counts as a difference — a diff that depended on which language you had selected would be a diff you could not trust.

For JSON specifically there is a distinction worth making. A text diff reports a reordered key as a change, because as text it is one. If the question is whether two documents mean the same thing regardless of key order and formatting, that is a structural comparison — the JSON Diff and JSON Compare tools do it properly.

Comparing tells you what differs. Merging is deciding what the combined result should be — going through the differences and choosing, for each one, what the final version says.

The merge helper above lists every changed block and offers three choices per block: keep the original, keep the modified, or keep both. The result is assembled from those choices and stays editable, so anything the three options do not cover can be typed by hand.

Every block starts unresolved, and that is deliberate rather than cautious — see the next section for why nothing can safely be chosen for you. Anything still unresolved appears in the result between conflict markers:

1<<<<<<< Original2const timeout = 30;3=======4const timeout = 60;5>>>>>>> Modified

These are the markers git uses, and they are deliberately not valid in any language — the result cannot be pasted anywhere until a person has dealt with them. Nothing is ever silently discarded.

This distinction is the reason the merge here asks you about everything, and it is worth understanding before trusting any merge tool.

Two-way

Two inputs: an original and a modified version. You can see every difference — and that is all you can see. When a line differs, nothing in the input says whether the left side changed it, the right side changed it, or both did. Those are three completely different situations and they look identical.

1Original  ──┐2            ├──▶  differences  ──▶  you decide, every time3Modified  ──┘

Three-way

Three inputs: the common ancestor both versions started from, plus the two versions. This is what git has, because it knows the commit both branches diverged from.

1Base   ──┐2Ours   ──┼──▶  compare each side to the base3Theirs ──┘4 5  matches base on one side, differs on the other6      → only one side changed it: take that side7 8  both sides differ from base, and from each other9      → a real conflict: ask

The ancestor turns most differences into arithmetic. If a line matches the base on one side and differs on the other, exactly one side changed it, and that side wins — no question needed. Only when both sides changed the same line differently is there a genuine conflict, which is far rarer than the number of differences suggests.

That is why git merges most branches without asking anything, and why a two-way tool cannot. With two inputs every difference is potentially a conflict, so presenting some of them as automatically resolved would be a guess dressed as an answer.

The practical reading: use this to combine two files you have in front of you — a config against a backup, a draft against an edit, generated output against a committed copy. When the two versions have a shared history, let git do it.

Mostly when you have two versions of something and no version control between them.

• Reviewing changes before committing. Reading a change as a diff catches the debug line you left in far more reliably than rereading the file.
• Comparing configuration files.A working config against a broken one, or a server’s against the version in your repository.
• Comparing JSON or API responses. What changed between two calls, or between a fixture and what the service now returns.
• Checking generated output. Whether a build, a migration or a formatter changed anything it should not have.
• Reviewing text revisions. What an editor changed in a draft, where word granularity earns its place.
• Investigating an unexpected change. Something works on one machine and not another, and the two copies of the file are the first place to look.
• Verifying a copy or a migration. Confirming that text survived an export, an encoding change or a move between systems intact.

When two versions do share a history, version control is the better tool: it knows the ancestor, merges automatically where it safely can, and records who changed what. This is for the cases where that history does not exist.