Diff Checker

How a text diff is computed

A diff answers a precise question: what is the smallest set of line additions and deletions that turns the first text into the second? This tool answers it with the classic approach — split both texts into lines, find their longest common subsequence (the longest run of lines that appears in both, in the same order), and treat every line not on that path as added or removed.

The longest-common-subsequence choice matters. It means moved blocks, inserted paragraphs and deleted sections are all reported as local changes rather than making everything after them look different. Lines that appear in both texts act as anchors that keep the two sides aligned. Each row shows the line number in the original text, the line number in the changed text, a +/− marker, and the line itself.

This is a line-level diff, not a character-level one. If a single word in a line changes, the whole old line is marked removed and the whole new line added — there is no inline word highlighting. That keeps the output simple and predictable, and it is what most code review and "what changed" tasks actually need.

The two options change how lines are matched, not how they are shown. "Ignore whitespace" trims each line and collapses internal runs of spaces before comparing, so reindented code or reflowed prose still lines up. "Ignore case" makes lines that differ only in capitalisation count as unchanged. For diffing JSON or code, formatting both sides with consistent indentation first gives the cleanest result.

The comparison runs entirely in your browser, so you can paste private code or documents. Unchanged lines at the start and end are matched before the table is built, so long files with a localised edit compare quickly; only very large rewrites — thousands of changed lines on both sides — are too big to compare here.

lines A, lines B → LCS table  dp[i][j] = length of longest common subsequence of A[i:], B[j:]
walk from (0,0): equal line → keep (unchanged)
  else step toward the larger of dp[i+1][j] (delete A[i]) / dp[i][j+1] (add B[j])

Worked example

Original:    Changed:
a            a
b            c
c            d
d            e

Result:
  1 1  a
− 2    b
  3 2  c
  4 3  d
+   4  e

Line b was removed and line e added; a, c and d are unchanged and keep both line numbers. A line that was edited — even by one character — appears as a removal plus an addition.

Getting a readable diff

• Format both sides the same way first. For JSON, run both through the JSON formatter with the same indentation; for code, use the same formatter settings — otherwise every line looks changed.
• Turn on “ignore whitespace” for re-indented code, and “ignore case” for SQL keywords or headings whose capitalisation changed.
• Long files with a few edits compare instantly, because identical lines at the start and end are matched before the comparison table is built.
• For whole documents that were heavily rewritten, compare section by section; very large rewrites are better handled by git diff or a desktop diff tool.