What this tool does

The Text Diff Checker takes two blocks of text, call them Original and Modified, and shows you exactly what changed between them. Added content is highlighted in green, removed content in red, and matching content stays neutral. You see the diff at a glance, no command-line diff invocation, no GitHub URL, no IDE.

It works at three granularities: line, word, and character. Pick the one that matches the question you're asking. "What rows changed in this CSV?", line. "Which sentence got reworded?", word. "Did someone slip a zero-width space into a UUID?", character.

How to use it

1. Paste your original text into the left editor. Paste your modified text into the right. 2. Pick a granularity with the segmented control: line (default), word, or char. 3. Pick a layout: unified (one column, additions and deletions interleaved like a Git diff) or side-by-side (two columns, original on the left, modified on the right). 4. Toggle Ignore whitespace to skip leading/trailing spaces and tabs that are not meaningful, useful when one source uses tabs and the other uses spaces. 5. Toggle Ignore case to treat HELLO and hello as identical, useful for case-insensitive identifiers, SQL, environment variable names.

The output card updates automatically as you type or toggle. Stats at the top of the diff show how many tokens were added, removed, or unchanged.

How the diff is computed

Both inputs are tokenised at the chosen granularity, then run through a longest-common-subsequence (LCS) algorithm. LCS finds the largest set of tokens that appear in the same order in both inputs; everything outside that subsequence is either an insertion (tokens present only in B) or a deletion (tokens present only in A).

This is the same family of algorithms that powers git diff, diff -u, and most IDE merge views. It's deterministic, the same two inputs always produce the same diff, and it's the right answer in the formal sense (smallest edit set), not just a "best guess".

For very large inputs the algorithm is capped at 5,000 tokens per side to keep your browser responsive. Beyond that cap, the tool falls back to a simple "everything in A removed, everything in B added" view rather than freezing the page.

Line vs word vs character diff

  • Line diff is what git diff shows by default. Best for code, configuration files, CSV, JSON Lines, and anything where the line is the natural unit. At line granularity, even a single-character change marks the entire old line as removed and the new line as added.
  • Word diff splits on whitespace. Best for prose, README updates, marketing copy, and emails, you see the actual edited words, not the rewritten paragraph as a wall of red and green.
  • Character diff splits on every character. Best for catching invisible differences, trailing spaces, smart quotes vs straight quotes, BOM markers, zero-width joiners, mismatched dashes (- vs – vs , ).

Common gotchas

  • CRLF vs LF line endings. Files copied from Windows have \r\n line endings; Unix files have \n. The tool normalises \r\n and \n for you, so you won't see a red diff on every single line just because of the platform.
  • Whitespace at the end of lines. Some editors strip trailing whitespace on save and some don't. If two visually identical files differ only there, switch to character granularity (or enable Ignore whitespace) to confirm.
  • Tabs vs spaces. A line indented with one tab and a line indented with four spaces look identical but produce a diff. Character granularity makes this obvious immediately.
  • Re-ordered identical lines. LCS only matches tokens in order. If you swap two lines, the diff shows one as "deleted from the old position" and one as "added at the new position", it doesn't say "re-ordered".

Privacy

Both text blocks stay in your browser. The diff algorithm runs locally, no upload, no logging, no server round-trip. Use the tool with proprietary code, customer data, internal documents, or anything else you can't paste into a third-party site.

Frequently asked

Are my two text blocks sent to a server?

No. The diff algorithm runs entirely in your browser using a longest-common-subsequence routine. Neither block is uploaded, logged, or persisted server-side. Safe to use with proprietary code, customer data, or anything confidential.

What's the difference between line, word, and character diff?

Line diff splits on newlines — best for code and config. Word diff splits on whitespace — best for prose where you want to see the actual edited words, not whole rewritten paragraphs. Character diff splits on every character — best for catching invisible differences like trailing spaces, smart quotes, or zero-width characters.

Why does my whole line show as changed when only one word differs?

You're using line granularity, where a line is either fully equal or fully different. Switch to 'word' granularity to see the actual edited tokens, or use the side-by-side view, which renders intra-line word changes within a modified line.

What's the difference between unified and side-by-side view?

Unified shows one column with deletions and additions interleaved, like 'git diff'. Side-by-side shows two columns, original on the left and modified on the right, with deleted lines aligned against added lines so you can read them in parallel. Use whichever matches the way you mentally model the change.

What does Ignore whitespace do exactly?

It strips leading and trailing whitespace from each line before comparing. Useful when one source uses tabs and the other uses spaces, or when a code formatter has reflowed indentation. It does NOT collapse internal whitespace — 'a b' and 'a b' will still differ.

Is there a size limit?

Yes — 5,000 tokens per side at the chosen granularity. Beyond that the LCS algorithm gets quadratically slow, so the tool falls back to a 'everything in A removed, everything in B added' view rather than freezing your browser. For larger files use a desktop diff tool.

How does it handle Windows vs Unix line endings?

CRLF (\r\n) is normalised to LF (\n) before tokenisation, so you won't see every line marked as changed just because one file came from Windows and the other from macOS or Linux.

Why does a re-ordered line show as one deletion and one addition?

LCS matches tokens in order. If you move a line from the top to the bottom of a file, the diff sees it as 'deleted from position N' and 'added at position M'. Diff algorithms generally don't model moves — that's a separate analysis on top of the basic diff.