Diff Checker
How it works
Paste the original text into Text A and the modified version into Text B. The tool aligns them line by line and prints one unified result: lines present in A but missing from B are red and prefixed with a minus (deletions), lines added in B are green and prefixed with a plus (additions), and unchanged lines stay neutral. A counter above the result gives the totals. The comparison is line-level, so a line with one changed word appears as a deletion followed by an addition rather than a highlight inside the line.
The comparison is a longest-common-subsequence (LCS) diff computed with the classic dynamic-programming table. It produces the same minimum-edit set of changes as `git diff`, `diff -u` and GitHub's PR view, which reach it by Myers' faster route, so if you swap one word in the middle of a paragraph, only that line changes and the surrounding context stays put.
Works equally well for: • Source code: see what changed between two versions of a function before committing • JSON / YAML / TOML config: spot the one key that differs between staging and production • Prose: compare two drafts of an article, contract, or email • Logs: diff two log excerpts to find the timestamp where behaviour diverged • CSV / TSV: track which rows changed in a spreadsheet export
Handling of common edge cases: • Trailing whitespace and CRLF/LF differences are flagged, because they change the byte content. There is no ignore-whitespace toggle, so if you only care about real changes, trim the input before you paste it. • Long lines wrap visually, but the diff treats each as one logical line; internally it is still character-by-character precise. • Mixed indentation (tabs vs spaces) shows up as a difference. Convert one side to match the other if you want only semantic changes. • Line endings at the end of the last line: if one file has a final newline and the other doesn't, the last line appears as a difference. This matches `diff -u` behaviour.
All comparison runs in your browser, in JavaScript. Two 5,000-line files compare in well under a second on a modern laptop; on phones the same comparison takes 1-3 seconds.
Frequently Asked Questions
What diff algorithm does it use?
- A longest-common-subsequence diff, computed with the classic dynamic-programming table. It returns the minimum-edit set of changes between two inputs, the same result `git diff`, GNU `diff -u` and GitHub's PR view produce with Myers' algorithm, so what you see here matches what you would see locally.
Can I compare code files?
- Yes. The tool is text-agnostic: paste two versions of a JavaScript, Python, Go or SQL file and it line-diffs them the way `git diff` does. There is no syntax-aware diff (it does not know that one line is JSON and another is HTML), but for the vast majority of code-review use cases line-by-line is exactly what you want.
How do I ignore whitespace differences?
- Pre-process your input: trim trailing spaces from each line, normalize tabs to spaces (or the reverse), and standardise line endings on LF or CRLF, one or the other. Running each side through Text Case Converter or any trim utility before pasting is a quick way to do it. There is no ignore-whitespace toggle: the diff always compares the exact characters of each line.
What's the difference between a line diff and a word diff?
- A line diff treats each line as one unit, so a single changed character marks the whole line as changed. A word (or character) diff highlights only the differing tokens inside a line. This tool does a line-level diff: change one character and the whole line is reported as a deletion plus an addition. There is no word-level highlighting inside a line.
Why are blank lines showing as different?
- Because they are different. An empty line at position 5 in Original, where the corresponding position in Modified is non-empty or absent, IS a difference, and the tool surfaces it. Many people find this surprising the first time, but it is correct behaviour: invisible characters carry meaning in Python indentation, YAML structure and Git commit messages.
What's the maximum file size I can diff?
- There is no hard cap, because everything runs in your browser. The LCS table is O(N×M) for inputs of length N and M, so two 100,000-line inputs take noticeable time (roughly 30-60 seconds on a modern laptop). For very large files, say two 50 MB log dumps, use a desktop tool; a browser tab is the wrong place for that scale.
Is my data sent anywhere?
- No. The diff algorithm runs entirely in your browser, and DevTools → Network confirms zero outbound requests when you paste and compare. This matters when you are diffing config files that contain credentials, contracts, source code under NDA, or anything else you would rather not paste into a random web page.
Diff modes: what each kind of comparison answers
Different ways to compare two texts. The line diff implemented here is the most common, but knowing the alternatives helps you pick the right tool for the right question.
| Mode | Granularity | Best for | Example use case |
|---|---|---|---|
| Line diff (this tool) | One line at a time | Source code, configs, structured logs | Reviewing a Git commit or PR |
| Word diff | Tokens within a line | Prose, single-paragraph changes | Comparing two versions of a paragraph |
| Character diff | Each character | Very short strings, names, IDs | Spotting one-letter typos |
| Side-by-side diff | Two-column line view | Visual code review with full context | git diff --side-by-side |
| Unified diff | Single column with @@ markers | Patch files, terminal-friendly review | git diff (default), patch -p1 |
| Semantic diff | Aware of language structure | Refactoring without trivial whitespace noise | diff-so-fancy, difftastic, semantic diff tools |
| 3-way merge | Original + two modifications | Resolving conflicts between branches | git merge conflict resolution |
| Binary diff | Byte-by-byte | Comparing executables, images, archives | bsdiff, xdelta (not text-based) |
All text-based diff modes ultimately rely on either Myers' algorithm (1986) or Hunt-McIlroy (1976, the original Unix `diff`). Modern git uses Myers' with patience and histogram heuristics for cleaner output on heavily-edited code.