Text Difference Checker

Where a diff tool earns its keep

Comparing two versions of a document by eye is slow and unreliable — our brains are remarkably good at skimming past exactly the change that matters. A diff tool removes the guesswork. Lawyers and paralegals compare contract revisions to find the clause the other side quietly rewrote. Writers and editors proofread edited drafts against the original to see every suggested change at a glance. Developers paste two versions of a config file or code snippet to spot the one line — a port number, an API key name, a boolean — that broke production.

It is just as useful outside professional work: checking what changed between two versions of a rental agreement, verifying that a "final_v2" document really only contains the agreed edits, or confirming that copied text matches its source before you rely on it.

How the comparison works

Under the hood, the checker uses the same family of algorithms as developer diff tools: it finds the longest common subsequence between the lines of the two texts — the largest set of lines that appear in both, in the same order — and then marks everything else as added or removed. That is why moved paragraphs show up as a removal plus an addition rather than an invisible "move".

Line mode marks whole lines as changed, which is ideal for prose, lists and structured text. Word mode goes further: when a line exists in both versions but with edits, it highlights the exact words that differ — "Monday" struck through in red, "Tuesday" inserted in green — so a single changed digit in a long line is impossible to miss.

Making the ignore options work for you

Real-world documents rarely differ only in content. One version gets reformatted, re-wrapped or re-cased, and a naive comparison drowns you in false positives. The ignore options filter that noise: "Ignore whitespace" treats lines that differ only in spaces, tabs or indentation as identical — essential when one version was run through a formatter. "Ignore case" treats "Apple" and "apple" as the same line, useful when comparing exported data. "Ignore blank lines" skips empty lines entirely, so re-paragraphed text compares cleanly.

Everything runs locally in your browser. Sensitive material — contracts, unpublished manuscripts, internal configs — is never uploaded, queued or logged, which is exactly what you want from a tool people paste confidential text into.

Unified or side-by-side — choosing a view

The unified view stacks everything in one column: removed lines in red directly above the added lines that replaced them, with unchanged lines for context. It is compact, it mirrors the diff format developers know from Git, and it is usually the fastest way to scan a long document because your eyes travel in a single direction.

The side-by-side view puts the original on the left and the revised text on the right, aligned row by row, with empty gaps where a line exists on only one side. It costs more horizontal space, but many people find it far easier to reason about — especially when reviewing prose with someone else, because each column reads as a complete, coherent version of the document.

A practical workflow: start in side-by-side to understand the shape of the changes, switch to unified plus word granularity to verify the details, and use the stats strip — added, removed, unchanged and similarity percentage — as a sanity check. A 99% similarity on a contract you were told was "heavily reworked" is worth a raised eyebrow; a 40% similarity on a "small tweak" deserves a careful read.