Diff Checker

This diff checker shows you exactly what moved between two versions. A proper longest-common-subsequence diff finds the real edits rather than the first mismatch, shows them side by side or unified, and can highlight the changed words within a changed line.

How to use Diff Checker

  1. Paste the original text on the left and the modified text on the right.
  2. Switch between side-by-side and unified views depending on how wide your screen is.
  3. Turn on word-level highlighting to see exactly which words changed inside an edited line.
  4. Use the ignore whitespace and ignore case options to filter out changes you do not care about.
  5. Copy or download the unified diff to paste into a review, an issue or a patch file.

About Diff Checker

A naive comparison walks two texts in lockstep and declares everything different from the first mismatch onwards. That is useless in practice, because the most common edit — inserting a line — shifts every subsequent line by one. A real diff solves a longest common subsequence problem instead: find the largest set of lines appearing in the same order in both versions, call those unchanged, and describe everything else as an insertion or a deletion. The result matches what a human would call the change.

This checker implements that properly. It trims the common prefix and suffix, splits large inputs at lines that appear exactly once on each side — the patience-diff anchoring trick that keeps big comparisons both fast and readable — and runs a dynamic-programming LCS on the remaining blocks. Paired deletions and insertions can then be compared again at word level, so a changed line shows precisely which tokens moved instead of lighting up in full.

The options are there because most diffs contain noise. Reformatting a file changes every line if you count indentation; a case-normalisation pass changes every line if you count capitals. Ignoring whitespace or case affects only how lines are matched, never how they are displayed, so you still see the original text with real changes highlighted. When you are done, the unified diff export gives you something to paste into a pull request, an issue or patch itself.

Frequently asked questions

How does the comparison work?

It computes a longest common subsequence over lines — the same family of algorithm Git and the Unix diff command use — so a single inserted line does not knock everything after it out of alignment. Large inputs are split at unique anchor lines first, which keeps the comparison fast without changing the result.

Is my text uploaded anywhere?

No. Both sides stay in your browser and the diff is computed in JavaScript on your device. That makes it safe for source code, contracts, configuration files and anything else you would not paste into a random web form.

Can it compare code and keep the indentation?

Yes. Whitespace is preserved and shown exactly, and the panes scroll horizontally rather than wrapping, so indentation-sensitive languages such as Python and YAML stay readable. If indentation churn is noise for you, switch on “ignore whitespace”.

What does word-level highlighting add?

When a line has changed, a line-level diff only tells you that. Word-level highlighting runs a second, finer comparison inside the paired lines and marks just the tokens that differ, which turns a rewritten sentence into a one-word correction you can see at a glance.

What is a unified diff?

The standard patch format: a single stream showing removed lines prefixed with -, added lines with + and a few lines of unchanged context around each change, grouped into @@ hunks. It is what git diff prints and what code review tools accept.

Is there a size limit?

No hard limit. Comparisons of a few thousand lines per side complete instantly; very large inputs are handled by anchoring on unique lines so the tool stays responsive rather than attempting a quadratic comparison.

Related tools

All developer tools · Browse all 56 free tools →