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 diffshows 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\nline endings; Unix files have\n. The tool normalises\r\nand\nfor 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.