Text Diff Tool
Compare two texts and highlight differences
Text Diff Tool
Compare two texts and highlight differences
Features
- Three diff granularities: line-by-line (the default — best for code, configs, prose paragraphs), word-level (best for plain prose where line breaks are stylistic), and character-level (best for ID strings, hashes, or single-line text)
- Two view modes: unified (one column, +/- prefixes; matches `git diff` output) and side-by-side (two columns, color-coded; better for spotting reordered passages)
- Per-comparison toggles for ignore-whitespace (collapses runs of spaces/tabs/newlines), ignore-case, and trim-lines (drops leading/trailing whitespace per line)
- Diff math uses Longest Common Subsequence (LCS) — same algorithm as `git diff`, with O(NM) complexity. For 10k-line files this completes well under a second; for 100k-line files the page will pause briefly
- Per-line numbering on both sides (left and right) so you can quote a specific line in a review without counting manually
- Swap button flips the two inputs and re-runs the comparison so you can confirm directional changes (added vs removed) without recopying
- Copy diff button writes the unified-format output to the clipboard ready to paste into a code review, ticket, or commit message
- Pure client-side: tokenization, LCS, and rendering all happen in your browser. No text is sent to a server, the page works offline once cached
How to use
- Paste your "before" text into the left textarea and the "after" text into the right.
- Pick the granularity: line for source code and configs; word for prose; character for short ID-like strings.
- Toggle ignore-whitespace if your inputs differ only by indentation or tab/space mixing. Toggle ignore-case for case-insensitive comparison.
- Choose view mode: unified for grep-friendly +/- output, side-by-side for visual scanning.
- Click Compare. The summary shows additions, deletions, and unchanged counts; the body shows the actual diff with line numbers.
- Click Copy diff to grab the unified form for sharing, or Swap to confirm directional changes.
Tips & Best Practices
- For reviewing config-file changes, use line + ignore-whitespace + trim-lines — surfaces real key-value changes without indentation noise.
- For reviewing prose edits (blog posts, docs), use word algorithm with unified view — reads naturally.
- For reviewing API responses or test fixtures, run JSON Formatter on both sides first to normalize formatting, then diff here in line mode.
- Side-by-side mode is best for spotting reordered passages; unified is better for sharing in a chat or commit message.
- When pasting from a terminal, watch for trailing whitespace — enable trim-lines to ignore it.
FAQ
What's the difference between line, word, and character diff?
Line diff treats each line as an atomic unit — any change inside a line shows the whole line as removed+added. Word diff splits on whitespace, so a typo fix inside a sentence only highlights that one word. Character diff splits per character, so a single letter change highlights one letter. Use line for code, word for prose, character for short identifier-like strings.
Does this match `git diff` output?
In unified mode with line algorithm, yes — the +/- prefixes and per-line layout follow the standard unified-diff format. The LCS algorithm is the same one `git diff` uses by default. Differences appear in word/char mode (git doesn't do that by default) and in this tool not yet supporting --color, --stat, or rename detection.
Why does ignore-whitespace not work how I expected?
Ignore-whitespace collapses runs of spaces/tabs/newlines to single spaces before comparing. It does not normalize indent levels — so ` foo` and `foo` would still differ if you didn't also enable trim-lines. For pure visual whitespace differences, enable both ignore-whitespace and trim-lines.
Can I diff files instead of pasted text?
Not yet — input is paste-only via the two textareas. For file diffs, paste the file contents (Ctrl-A, Ctrl-C in your editor, paste here) or use `git diff` locally and paste the output.
How big can the inputs be?
Practical limit ~100k lines per side before the UI pauses noticeably during LCS computation. For larger inputs, run `diff` locally (it's in every Unix and modern Windows), or chunk the inputs by section and diff each section here.
Why do I see lots of "unchanged" lines in word/char mode?
Word and char algorithms tokenize the entire input as one stream and find the longest common subsequence at that granularity. Long shared passages produce many small unchanged tokens (single spaces, punctuation marks). The summary count reflects token count, not line count, in those modes.
Is the diff sent anywhere?
No. Both inputs and the resulting diff stay in your browser; the LCS runs synchronously in the tab; DevTools Network shows no requests when you click Compare. The page works offline.
What's the LCS algorithm and why does it matter?
Longest Common Subsequence finds the maximum-length sequence of elements that appear in the same order in both inputs (not necessarily contiguous). Once you know the LCS, everything not in it is either added or removed. Standard textbook algorithm (Hirschberg/Hunt-McIlroy variant) used by `diff`, `git diff`, and most diff libraries.