Text Diff Checker

About the Text Diff Checker

Both texts get tokenized into words, then compared with a real Longest Common Subsequence algorithm, the same core technique behind source-control diff tools, to find the minimal set of changes between them. Removed words show struck through in red, added words are underlined in green, and everything else stays exactly as it was.

The same core algorithm behind git diff and the Unix diff command

Longest Common Subsequence finds the longest sequence of tokens that appears, in order, in both texts, without requiring them to be adjacent — everything not part of that shared sequence is what actually changed. This tool builds a full dynamic-programming table sized to the word count of each text, fills it working backward from the end of both texts, and then walks forward through that table to reconstruct the specific sequence of equal, removed, and added tokens that produces the minimal possible diff. That's the same fundamental technique — not an approximation of it — that source-control tools like Git and the classic Unix diff command are built on, which is why the highlighted result here shows a genuinely minimal set of changes rather than something closer to a rough guess.

Punctuation stays glued to its word, so a punctuation-only edit shows as a full word swap

Tokenizing is done with /\S+|\s+/g, which splits text into runs of non-whitespace and runs of whitespace, but doesn't separate a word from punctuation directly attached to it. That means "hello," and "hello" are two entirely different tokens as far as the diff algorithm is concerned — changing one to the other by just deleting a trailing comma registers as a full word removed and a full word added, not as a small, isolated punctuation change. For diffs where you specifically care about tracking wording changes versus punctuation cleanup separately, keep in mind that this tool doesn't distinguish between the two; both show up identically as a word-level add/remove pair.

Whitespace differences are preserved in the layout but never visually flagged

Every run of whitespace between words is its own token too, and it goes through the same diffing process as words do — but the isWordToken() check that decides whether to count a token in the Added/Removed/Unchanged stats, and whether to wrap it in a highlighted <del> or <ins> element, only applies to non-whitespace tokens. So if two versions of your text differ only in spacing — an extra space, a different number of blank lines between paragraphs — that difference is correctly reflected in how the final text renders, but it won't show up as a visible strikethrough or underline, and it won't move any of the three word-count stats. Purely whitespace-only edits are effectively invisible in this tool's output.

Performance scales with the product of both texts' lengths, not their sum

Because the algorithm builds a table with one row per token in the original text and one column per token in the changed text, the total work and memory involved grow with the product of the two word counts, not just their combined total. Comparing two 200-word paragraphs means a table around 40,000 cells, which is instant; comparing two lengthy multi-thousand-word documents can mean a table in the tens of millions of cells, which is measurably slower and more memory-intensive. For everyday paragraph or short-document comparisons this is a non-issue, but pasting two very large documents is where you'd start to notice this tool taking longer to return a result.

Comparing runs only when you click, not on every keystroke

Unlike most tools on this site, the diff doesn't recompute as you type in either textarea — it waits for the Compare button. Given that the underlying algorithm's cost grows with the product of both texts' lengths rather than staying cheap and constant, running a full comparison after every single keystroke in either box would mean redoing a potentially large calculation dozens of times over while you're still mid-edit, for no benefit until you're actually ready to see the result. Requiring an explicit click keeps the tool responsive regardless of how long the two texts you're comparing happen to be.