Text Diff Checker - Compare Two Texts Online

Why position-by-position comparison fails

The obvious way to compare two texts is to line them up and check line 1 against line 1, line 2 against line 2, and so on. It breaks the moment someone adds a line. Insert one sentence at the top of a 200-line document and every line below shifts down by one, so a naive checker reports 200 changes when there was really one.

Real diff tools solve this by finding what the two versions have in common first, then reporting only what is left over. This checker does exactly that, which is why its output reads like a git diff instead of a wall of red.

The algorithm: longest common subsequence

A subsequence is a set of lines that appear in the same order in both texts, though not necessarily next to each other. The longest common subsequence, or LCS, is the biggest such set. Those lines are unchanged. Every line in the original that is not in the LCS was removed, and every line in the new text that is not in it was added.

The tool builds a table with one row per original line and one column per new line, fills it with the LCS length for every pair of prefixes, then walks back through it to produce the diff. That takes time and memory proportional to the two line counts multiplied together. Two 4,000-line texts mean 16 million table cells, which is why inputs above roughly 4,000 lines each are capped. Past that, a browser tab starts to stall.

The comparison runs on every keystroke, so you can fix a line in either box and watch the diff update. Both boxes start with sample text so you can see the output format before pasting your own.

Worked example

Original, four lines: apples, bananas, cherries, dates. New version, five lines: apples, blueberries, cherries, dates, elderberries. The longest common subsequence is apples, cherries, dates, three lines.

So the result is: apples unchanged, bananas removed (-), blueberries added (+), cherries and dates unchanged, elderberries added (+). The summary reads 2 added, 1 removed. A position-based checker would have flagged line 2 and then called line 5 new, which happens to match here, but insert a line at the top and it falls apart while LCS does not.

When to use the ignore options

Ignore leading and trailing whitespace is the one you will want most often. Text copied from a PDF, an email, or a different editor often picks up trailing spaces or different indentation. With the option on, a line that differs only in surrounding spaces counts as unchanged. Spaces in the middle of a line still count.

Ignore case helps when one version went through a style pass, such as headings changed to title case, and you only care about wording. Leave it off for code, passwords, and anything where case carries meaning.

Reading the output without getting fooled

This is a line diff. A one-word edit shows up as the whole old line removed and the whole new line added, usually right next to each other. Scan those pairs to find the changed word. Long paragraphs pasted as a single line make this harder, so for prose, break text into one sentence per line before comparing if you want tighter results.

Line endings and invisible characters can cause phantom differences. A line with a non-breaking space or a zero-width character looks identical on screen but will not match. If two lines look the same and still show as changed, clean both sides with the whitespace cleaner and compare again.

Reformatted code is another trap. If one version was run through a formatter, most lines change even though the logic did not. Format both sides the same way first.

Common uses

Editors compare a writer's draft against the published copy. Students check what changed between essay versions. Developers compare config files, environment variables, and SQL snippets without committing anything. Anyone reviewing a contract or policy can see exactly which clauses moved, appeared, or disappeared between two versions.