Loading Text Diff Checker…
3 changes
2 changed · 1 added · 0 removed · 40% the same
Both texts stay in this page — nothing is uploaded, which matters when the thing being compared is a contract. Lines are matched with a longest-common-subsequence diff, the same approach diff and every code review tool use, so a line inserted in the middle shifts everything below it without being reported as a hundred changes.
Two versions of the same document and no record of what happened in between: a contract returned by the other side, a paragraph a colleague rewrote without tracking anything. This checker takes both texts and reports the difference, line by line or word by word, with counts of how many lines changed, were added and were removed, and a percentage of the document that stayed the same.
The options cover the differences that are not really differences. Capitalisation and spacing can each be ignored, and unchanged lines can be hidden so that a long file collapses to the parts worth reading. The result can be copied out as a unified diff for pasting into a ticket or a commit message.
Comparing a four-line document against a five-line revision of it reported 2 changed, 1 added, 0 removed, and 40% the same.
The second line is the interesting one. "jumps over the lazy dog" against "leaps over the lazy dog" comes back as a single changed line with only the first word marked, rather than as one deletion followed immediately by one insertion. Reading an edited line as a pair of unrelated lines is what makes a lot of diff output so tiring to read.
The unified diff produced for that same comparison is byte-identical to what diff -u prints for the two files.
The matching is a longest-common-subsequence diff, the same family of algorithm behind diff(1) and the review screens in code hosting tools, described in Myers, "An O(ND) Difference Algorithm and Its Variations", 1986. It looks for the longest run of material the two versions genuinely share and treats whatever is left over as inserted or deleted, rather than comparing line 1 against line 1 and falling apart the moment the two get out of step.
Identical material at the start and end of both documents is matched off before the comparison table is built. That is what makes two long drafts of one document cheap to compare: where a couple of paragraphs moved in the middle of something long, most of the work never happens.
Comparison and display are kept apart. Ignoring case or ignoring spacing changes what counts as equal while the matching runs, and never changes what appears on screen — the lines shown are the lines you pasted.
Neither text is uploaded. Both stay in the page, which is the point when the thing being compared is a contract or an unreleased draft. The alternative is posting two versions of a confidential document to somebody else’s server to discover that one comma moved.
Very large pairs are not lined up exactly. Past a certain size the tool declines the exhaustive match and says so on screen: a stated approximation is worth more than a precise answer that arrives once the tab has frozen.
Line mode for code, configuration and anything where a line is the unit of meaning. Word mode for prose, where a rewritten sentence would otherwise show as a whole line replaced when the real edit was three words.
The share of lines that matched, not a measure of meaning. Reformatting a document without altering a single word can drop the figure sharply, and swapping one crucial "not" can leave it in the high nineties.
Because matching and rendering are separate steps. The option tells the comparison to treat two lines with different spacing as equal; the panel still shows each line exactly as pasted, so nothing is quietly rewritten on your behalf.
Only context. The counts and the percentage are worked out across the whole document either way, so collapsing the matched sections changes what is on the screen and not what is reported above it.