Diff Checker

How the comparison works

The tool computes a longest common subsequence between the two texts at line granularity. That means it finds the largest set of lines appearing in both, in the same order, and treats everything else as inserted or deleted.

This produces a genuinely minimal diff rather than a naive line-by-line comparison. Insert a paragraph at the top of a document and a naive comparison reports every subsequent line as changed; an LCS diff correctly reports one insertion and leaves the rest marked unchanged.

A modified line appears as a deletion followed by an insertion, because at line granularity there is no such thing as a partial change. That is standard behaviour for line diffs and is why an edited word shows the whole line twice.

The ignore options and when to use them

Ignore whitespace collapses runs of spaces and strips leading and trailing space from each line before comparing. Use it when comparing code that has been reindented, text that has passed through different editors, or anything where the layout changed but the content did not.

It is exactly the wrong option for languages where indentation is meaningful, Python and YAML being the obvious cases. There, a whitespace change is a semantic change and hiding it will mislead you.

Ignore case is useful for comparing text where capitalisation is inconsistent but immaterial — data extracted from different sources, or headings restyled. Turn it off for anything where case carries meaning, including most code.

Practical uses

Contract and policy revisions are the most common non-technical use. Comparing two drafts shows exactly what a counterparty changed, including the quiet single-word edits that are easy to miss on a read-through — and those are frequently the ones that matter.

Configuration files are the most common technical one. Comparing a working config against a broken one usually isolates the problem in seconds, where reading both in full might not.

Content editing benefits too: comparing your draft against an editor's returned version shows precisely what was altered, which is more useful than a general sense that it was tightened.

The summary counts at the top give a quick sense of scale before you read the detail — a change of three lines out of four hundred is a different proposition from a rewrite.

Limits worth knowing

The algorithm is quadratic in time and memory, which is fine for the sizes people paste into a web page and not fine for very large files. A cap of 5,000 lines per side prevents a huge paste from locking up the tab; beyond that, a desktop diff tool is the right instrument.

The comparison is line-based, so it will not highlight which word within a line changed. For prose, where a paragraph may be one very long line, that can make the output less useful than it looks — breaking the text into sentences per line first gives a much more readable diff.

Both texts remain in the page. Nothing is sent anywhere, which matters when the thing you are comparing is a contract or a private configuration.