difference Text Compare (Diff Checker) star

How the Comparison Works

The tool splits both texts into lines and runs a Longest Common Subsequence (LCS) algorithm — the same core logic Git and code editors use for their "diff" view. Instead of comparing lines by position (line 1 vs line 1, line 2 vs line 2), LCS finds the longest sequence of lines that appears, in the same order, in both documents. Everything inside that shared sequence is marked unchanged; whatever is left over in the original is marked removed, and whatever is left over in the revised text is marked added.

This distinction matters because a naive positional comparison breaks the moment a single line is inserted or deleted near the top of a document — every line after it would appear to differ, even though nothing actually changed except that one line. Concrete example: if the original reads "A / B / C / D" and the revised text reads "A / X / B / C / D", a simple line-by-line comparison would flag B, C and D as all changed, since they have each shifted down one position. LCS instead recognizes that A, B, C and D still appear in the same relative order in both texts, so it correctly reports only one addition — the new line X — and marks the rest unchanged.

What to Know

• Line-based, not word-based: the comparison operates on whole lines. Changing a single word inside a long line still marks that entire line as one removed plus one added line — the standard convention in code and document diffing, since it keeps the output easy to scan.
• Whitespace and case count: a trailing space or a different letter case makes two otherwise identical lines register as different — worth normalizing your text first if that is not the comparison you want.
• Reordered content is matched correctly: because LCS looks for the longest common sequence rather than exact positions, a paragraph that moved elsewhere but kept its internal line order is recognized as unchanged rather than as a delete-then-add pair.
• Large documents scale fine: the algorithm handles thousands of lines comfortably; extremely large files (tens of thousands of lines) may take the browser a moment longer to align, but nothing is ever uploaded — the computation stays local the whole time.

The same technique underlies "track changes" style review outside of programming too: a legal team comparing two drafts of a contract clause, an editor checking exactly what a co-author rewrote in a chapter, or a translator confirming which sentences shifted between two localized versions of a document. Because the algorithm only cares about the sequence of lines, not what they mean, it works identically well on source code, configuration files, poetry, or a spreadsheet exported as plain text.