Text Diff Checker

What a diff actually does

Comparing two texts by eye fails for a specific reason: humans are good at spotting that something changed and bad at spotting that nothing did. Twenty identical lines followed by one altered digit is exactly the shape of problem our attention is worst at. A diff inverts the task — it aligns the two documents so that everything identical lines up and falls away visually, and only the differences are left to look at.

The alignment is the interesting part. A naive comparison walks both sides line by line, so inserting a single line at the top makes every subsequent line appear changed. A real diff algorithm finds the longest common subsequence of the two documents first — the same O(ND) difference algorithm Eugene Myers published in 1986, which is still the basis for the diff engine in Git, VS Code and most modern editors — then reports the insertions and deletions needed to turn one into the other. That is why adding a paragraph to the middle of a document shows up as one added block rather than as a cascade of shifted lines, and it is the difference between a diff you can read and a wall of red and green.

This page uses the same diff engine that powers VS Code's side-by-side comparison view, which means the behaviour is one you already know: matching lines aligned across the two panes, added lines marked on the right, removed lines on the left, modified lines shown on both with the changed characters highlighted inside them, and unchanged regions foldable so a long document collapses to its interesting parts. Both panes stay editable, so the tool doubles as a scratch space — fix the difference on the spot and watch the highlighting disappear.

The comparisons people actually run

Configuration drift is the commonest. Staging works and production does not, and the answer is somewhere in two nearly identical environment files or two copies of a service config. Paste both, and the six lines that differ separate themselves from the two hundred that do not. The same shape of question comes up between two servers' output, two versions of a deployment manifest, and a template against the file that was generated from it.

Log comparison is the second. A request that succeeded and one that failed produce two log extracts that are 95% identical, and the 5% is the bug. Diffing them beats reading them. So does comparing a captured HTTP header block against a working one, or two runs of the same script's output where one produced the wrong number.

Then there is text as text. Two drafts of a document where you need to know what an editor changed. A licence header that must be byte-identical across a hundred files. Two versions of a prompt, where a single word changed the model's behaviour and you would like to know which. A CSV export from before and after a migration. Two SQL queries that are supposed to be equivalent. In every one of those cases the alternative is reading both versions carefully, which takes ten minutes and misses things; the diff takes ten seconds and does not.

A tip for noisy diffs: if the two sides differ mostly in formatting rather than content, normalize first and compare second. The String Utility will trim trailing whitespace, collapse runs of spaces, or sort lines, any of which can turn an unreadable diff into a two-line one. For JSON, sorting both documents' keys before comparing has the same effect, and JSON Compare is the better page for that content anyway.

Normalize before you compare

Most unreadable diffs are not caused by the content differing — they are caused by the presentation differing, and a diff cannot tell the two apart. Four causes account for nearly all of it, and each has a one-step fix worth applying before you look at the result.