Text Diff Checker

What a diff actually computes

A diff answers a deceptively simple question: what is the smallest set of edits that turns text A into text B? Answering it well is a classic algorithms problem. The standard approach builds an edit graph and finds the longest common subsequence (LCS) — the longest run of lines that appears in both texts in the same order. Everything not in that subsequence is an insertion or a deletion.

This tool uses a dynamic-programming LCS, which is exact and easy to reason about. It requires memory proportional to the product of the two line counts, which is why there is a size guard: a few thousand lines on each side is instant, but two 50,000-line files would need 2.5 billion cells and will be refused. Production tools such as git diff use Myers' algorithm, which is linear in the size of the change rather than the size of the file — a key reason git stays fast on enormous repositories.

Line-level vs. character-level diff

This tool diffs line by line, which is what you want for code and configuration: a changed line is shown as removed and re-added. Character-level diffs exist too and are better for prose, where a single sentence may have been edited inside an otherwise-unchanged paragraph.

When you look at a diff output, the convention is universal:

• + green — present in B, absent from A (added)
• - red — present in A, absent from B (removed)
• unchanged — context, shown so you can see where the change sits

Why diffs sometimes look "wrong"

Diff algorithms have no understanding of your intent — only of text. A function moved from the top of a file to the bottom is reported as a large deletion plus a large insertion, even though you changed almost nothing semantically. Moving a block one line down can produce a confusing diff if the algorithm anchors on a different common line than you expected. This is normal, not a bug.

The practical fixes: enable ignore whitespace when comparing reformatted code, and diff in small, coherent commits rather than one enormous change. A 20-line diff that a reviewer can hold in their head produces better reviews than a 2,000-line diff that nobody actually reads.

Whitespace-only changes

Nothing pollutes a code review faster than a diff where every line changed because someone's editor reformatted the file. The ignore whitespace option collapses runs of spaces and tabs before comparing, so you see only substantive changes. From the command line the equivalents are:

git diff -w              # ignore all whitespace
git diff --ignore-blank-lines
git diff --ignore-space-at-eol
diff -w fileA fileB      # classic Unix diff

A good team convention: never mix formatting changes with logic changes in the same commit. Run the formatter as its own commit, and reviews stay readable.

Practical uses beyond code review

• Comparing configuration between environments — paste the staging and production configs side by side and find the drift. This is the fastest way to answer "why does it work in staging but not production".
• Contract and policy redlines — paste two versions of a document and see exactly which clauses changed.
• Verifying a find-and-replace — run the replacement, diff before and after, and confirm it touched only what you intended.
• Checking generated output — diff two runs of a generator to confirm a code change did not alter output.
• Debugging encoding problems — if two strings look identical but compare unequal, a diff with whitespace visible will usually reveal an invisible character, a non-breaking space, or a different line ending.

Line endings: the invisible difference

Windows uses CRLF (\r\n); macOS and Linux use LF (\n). A file shared between them can show every line as changed even though not a single character of visible text differs. Git handles this with core.autocrlf; for manual comparison, normalise line endings first, or use the whitespace-insensitive mode.

Frequently asked questions