Text Diff
Compare two text blocks side by side with line, word, or character resolution
function greet(name) { if (!name) return "hello"; return "hello, " + name; function greet(name = "world") { return `hello, ${name}`; }
How to Text Diff Online
Compare two text blocks side by side with line, word, or character-level highlighting.
- Paste the original text into the left textarea and the changed version into the right.
- Pick a granularity: line (default, best for source code), word (best for prose), or character (best for short strings).
- Optionally enable 'Ignore whitespace' if you want to suppress formatting-only differences.
- The diff renders below as you type — green for additions, red strikethrough for removals, plain text for unchanged content.
- Read the stat badges to see total characters added, removed, and unchanged.
- Select the diff output to copy any portion to your clipboard.
About Text Diff
Comparing two pieces of text is one of those tasks that sounds trivial and turns out to be deep. Show two strings to a human and they can usually spot the differences. Show two thousand-line files and the human is suddenly hopeless — which is why every developer has a deep, instinctive reliance on **diff tools**. `git diff`, GitHub PR views, code review applications, document collaboration editors, and merge tools all depend on the same fundamental computation: find the shortest edit script that transforms one sequence into another.
The algorithm under the hood here is **Myers diff**, published by Eugene W. Myers in 1986 and the basis for virtually every modern diff implementation including `git diff`, GNU diff, and most IDE built-in comparators. The clever idea is that diffing reduces to finding the shortest path through a graph whose vertices are pairs of positions in the two inputs, with edges for "advance both sides" (a match) and "advance one side" (an insertion or deletion). Myers showed how to do this in time proportional to the sum of input lengths and the number of differences, which is fast in practice because real-world inputs are usually similar.
The implementation here is the **`diff` package** (jsdiff), which is the most widely-deployed JavaScript port and the engine inside many code editors, GitHub-clone projects, and review tools. It exposes three granularities, and the choice matters more than people often realize:
- **Line diff** is what `git diff` does. It treats each line as an atomic unit. This is the right default for source code, where any change to a line you care about is a change you want to see, and the line numbers are the natural anchors for review. - **Word diff** breaks the input into word tokens. This is dramatically better for prose, paragraphs of natural language, and documentation. A single typo in a long sentence shows as one word changed rather than the whole line being marked as different. - **Character diff** goes finest. It is the right pick when you are debugging why two short strings differ — a URL with a trailing slash, two near-identical UUIDs, similar-looking error messages. For long inputs char-mode is overkill and produces a wall of tiny hunks.
The **Ignore whitespace** option is unusually useful. It collapses runs of whitespace into a single space and trims both inputs, then runs the diff on the normalized result. This is what `git diff -w` does and is invaluable when you want to know whether a refactor actually changed code or just reformatted it. Pasting a JSON document minified on one side and pretty-printed on the other will, with this option enabled, show "no differences" — which is the correct answer if the JSON contents are identical.
A few practical hazards. The Myers algorithm is **O(ND)** for typical inputs but can degrade to **O(N²)** on completely-different megabyte-sized inputs — keep your test cases under a few hundred kilobytes for fast results. For genuinely large files, `diff -u` at the command line is faster and pipes cleanly into other tools. Trailing newlines are treated as part of the preceding line, which matches `git` behavior but can produce hunks that look subtly off if your files differ only in whether they end with a newline.
Everything runs in your browser. The jsdiff package is small (~30 KB compressed) and the React rendering uses simple span elements with Tailwind backgrounds — no virtual scrollers, no heavy editor framework. Confidential code, internal documentation, and proprietary content all stay in your tab; the page makes zero network requests during diff computation.
Related Tools
Frequently Asked Questions
What algorithm computes the diff?
The classic Myers diff algorithm — the same algorithm `git diff` and most code review tools use. It produces the shortest edit script between two sequences (lines, words, or characters). The implementation is the `diff` (jsdiff) library, which Mozilla's deep-diff tools and many code editors depend on. The output is always optimal: no shorter sequence of insertions and deletions exists that transforms left into right.
When should I pick line / word / char granularity?
**Line** is the right default for source code, configs, and structured text — `git diff` works this way. **Word** is right for prose, paragraphs, and documentation where a single typo would otherwise mark the whole line as changed. **Char** is for very fine-grained changes — comparing two URLs, two passwords, or two short identifiers. Char-mode produces the longest output for typical inputs because every changed character becomes a separate diff hunk.
What does 'Ignore whitespace' do?
It collapses runs of whitespace (spaces, tabs, newlines) into a single space and trims both sides before diffing. Use it when you want to compare two snippets that differ only in formatting — say, the same JSON minified vs. pretty-printed. Without the option, every change in indentation or newline placement counts as a diff hunk; with it, formatting changes vanish.
How big a comparison can the tool handle?
The Myers algorithm is O(ND) where N is the input length and D is the number of edits, so identical or nearly-identical inputs are fast even at megabytes. Pathological inputs (two completely different megabyte-sized texts) can hit O(N²) and freeze the page — keep inputs under a few hundred kilobytes for guaranteed-fast results. For huge files use `git diff` or `diff -u` at the command line.
Why do my hunks sometimes look weird around blank lines?
Line-mode diff treats trailing newlines as part of the previous line. If one side ends with a newline and the other does not, you may see a 'no newline at end of file' style hunk. This matches `diff -u` behavior and is significant when the file is supposed to be POSIX-compliant (POSIX requires files end in newline).
Can I copy the diff output?
Select the diff area and copy as you would any text — the result will be the original text with added and removed runs marked as you see them. For a machine-readable diff format, use the JSON Diff tool (for JSON specifically) or run `diff -u` at the command line, which produces standard unified-diff syntax that `git apply` and `patch` understand.
Is my text sent to a server?
No. The diff library and the rendering both run in your browser. No network requests, no logging. Confidential code, internal docs, and any other content stays in your tab.