Text Diff Checker

Text Diff Checker

Compare two texts and highlight differences side by side. Find changes between files, code versions. Free online text comparison diff tool

A diff tool that highlights "the line changed" is barely useful — your eyes can do that. The interesting questions are: did indentation change? Did line endings flip from LF to CRLF? Did a Unicode character get substituted with a homoglyph? This diff aligns the two inputs with the Myers algorithm, surfaces character-level edits inside changed lines, and flags the invisible diffs that explain most "the code looks identical but tests fail" bugs.

What kind of diff this actually computes

Line-level alignment uses the Myers diff algorithm (1986), which is what git diff, GNU diff, and most IDEs use. Within changed lines a secondary character-level diff runs to highlight intra-line edits. Lines that are added or removed in their entirety are not character-diffed (would be visual noise).

You will see four states per line: equal (unchanged, shown for context), added (only in right), removed (only in left), and modified (both sides changed, with character-level highlights). For 200-line inputs, expect roughly 10ms compute time — fast enough that the diff updates live as you type.

Working example: a sneaky one-line change

Input

Left:
  if (user.role === "admin") {
    return true;
  }

Right:
  if (user.role === "admin") {
    return true;
  }

Output

Visible diff: identical.

Hidden diff:
  Right line 1 contains a Unicode RIGHT DOUBLE QUOTATION MARK ("U+201D)
  Left line 1 has a regular ASCII double quote (")

This tester flags the codepoint difference; a typical line-only diff would say "identical".

This is the class of bug that "works on my machine, fails in CI" turns out to be. Smart-quotes from a paste, mixed tabs/spaces, NBSP instead of regular space — all look identical in any monospace font.

What the diff modes do

  • Line diff — default. Each side parsed as text, aligned line by line. Best for code and prose.
  • Word diff — splits on whitespace before aligning. Useful for paragraphs where line wrapping changed but content did not.
  • Character diff — every character independently. Use for short strings where you suspect a single-character bug (a typo in a constant, an off-by-one in a regex).
  • Ignore whitespace — collapses runs of spaces/tabs. Good for "did the actual code change?" when an autoformatter touched indentation.
  • Ignore case — folds A=a. Useful when comparing config keys across case-insensitive sources.

When to reach for this tool

  • Two test environments return JSON that should be identical but a comparison test fails — paste both responses and find the field that drifted.
  • You merged a PR and the build broke; you suspect a whitespace change snuck in. Compare your local working copy to origin/main.
  • A user reports "the prompt is different" but you cannot see how — paste the two and let character-level highlighting find the curly quote, the trailing space, or the missing newline.
  • You are reviewing translations of the same paragraph and want to focus on what actually changed between revisions rather than re-reading both versions.

What this tool will not do

  • It will not produce a unified-diff patch you can git apply. The visual format is for human review; for machine-readable patches use git diff or diff -u.
  • It will not do semantic diffing of JSON or XML structure. {"a":1,"b":2} and {"b":2,"a":1} are line-different but structurally identical. Use the JSON Tree Diff tool for that.
  • It will not handle arbitrarily large files in the browser without slowing down. The Myers algorithm is O(N×D) where D is the edit distance — for two 50KB files with significant changes, expect a noticeable pause.

Both inputs stay in your browser. Useful for comparing access logs, internal config files, or anything sensitive that you would not paste into a hosted diff service.

Frequently asked questions

Why does the diff highlight what looks like the same line as different?

Almost always one of: trailing whitespace, mixed tabs and spaces, CRLF vs LF line endings, or a Unicode codepoint that looks like ASCII but is not (smart quotes, NBSP, en-dash, fullwidth Latin). Enable "show whitespace" and "show non-ASCII" modes to see them.

How do I diff two JSON files where keys are in different order?

A line diff will show every reordered key as a change. Either sort keys first (jq -S . file.json) before pasting, or use a structural JSON diff tool that compares trees, not text.

Can it tell me how many lines actually changed?

Yes — the summary shows additions, deletions, and modifications. For purely-moved lines (cut from one place, pasted into another) both sides will show changes; Myers does not detect moves natively, only insertions and deletions.

What is "Myers diff" and is there a better algorithm?

Myers diff (1986) finds the shortest edit script in O((N+M)D) where D is the edit distance. It is what git, hg, and most IDEs use. Patience diff (used in some git modes) produces better-looking hunks for source code by anchoring on unique lines first. Histogram diff is git's default since 2.31 — same idea, faster.

How do I see whitespace differences?

Toggle "show invisibles" — spaces render as middle-dots, tabs as arrows, line endings as ⏎ or ¶. The character-level diff inside modified lines highlights exact whitespace changes.

Why does the diff slow down on a 10MB log file?

Diff algorithms are quadratic-ish in the worst case. For multi-megabyte inputs, either pre-grep both files to the lines you care about, or use command-line diff which streams better. Browser-based diffing is best for files under ~1MB.

Related tools

Last updated · E-Utils editorial team