Text Diff Viewer
Paste two texts. See exactly what changed — line by line in side-by-side view, or unified-diff format you can copy into a patch file. Word-level highlighting on changed lines so you spot the actual edit, not the noise around it.
What this tool does
- Side-by-side view — two columns with line numbers, deletions on the left, insertions on the right, and word-level highlighting on paired changed lines.
- Unified view — Git-style
+/-output. Copy the result and paste into a patch tool (git apply,patch). - Ignore whitespace — collapses LF/CRLF differences, indentation churn, trailing spaces. Useful for comparing pre/post-formatter versions.
- Ignore case — for comparing config files where case isn't significant.
- Line stats — at-a-glance count of additions, deletions, unchanged.
- Word-level highlighting — within paired changed lines, only the actually-changed substrings are marked. Less visual noise than full-line highlighting.
Common use cases
- Code review when GitHub's diff isn't enough — paste the two versions and get a clean side-by-side without the surrounding chrome.
- Config drift — compare two versions of a config file (Nginx, Caddy, .env) to find what's different.
- Document review — track-changes in a Word doc or Google Doc has its own UI; sometimes you just want to compare two plain-text exports.
- JSON drift — format both with the JSON formatter first (sorted keys, consistent indent), then diff. Catches API response changes.
- Email or message comparison — "did the wording really change between draft A and B?"
Why client-side
Comparing two texts is a great example of "obvious to upload, no reason to." The data you'd be sending — emails, internal docs, proprietary code — is often the most sensitive thing on the page. The math is small enough that running it in your browser costs you nothing.
This tool ships about 4 KB of JS for the full diff engine plus word-level highlighting. The LCS algorithm is the same one Git used in its early versions; modern Git uses Myers, which is faster on large inputs but produces near-identical results on typical inputs.
Limitations
- No three-way merge — this is a 2-way diff. For merge-conflict resolution, use
git mergetool. - No JSON / YAML structural diff — line-based only. Format both inputs with sorted keys to approximate it.
- Very large inputs (10K+ lines) may be slow; the O(N×M) LCS is fine for typical inputs but not for entire codebases.
- No syntax highlighting in the diff output. Out of scope; copy into your editor for that.
Related tools
- json.tooljo.com — format both JSONs (sorted keys, consistent indent) before diffing for a near-structural compare.
- md.tooljo.com — for diffing markdown documents, paste rendered HTML for a content-level comparison.
- hash.tooljo.com — for the "did anything change" question without caring about *what* — hash both, compare hashes.
FAQ
Is anything I paste sent to a server?
No. Both inputs and the diff calculation run in your browser — open DevTools → Network and confirm. Your code never leaves your device.
What algorithm does this use?
Longest Common Subsequence (LCS) with backtracking — O(N×M) time and memory. For typical inputs (tens to hundreds of lines per side) this is instant. For very large inputs (thousands of lines), Myers' O((N+M)·D) algorithm is faster; we'll add it if the LCS approach hits a wall in practice.
What's the difference between side-by-side and unified view?
Side-by-side shows the two texts in parallel columns with deletions on the left, insertions on the right, and changed lines paired with word-level highlighting. Best for code review and visual comparison. Unified shows one column with - lines for deletions, + for insertions, and unchanged lines in between — the format Git emits and the one most diff/patch tools accept as input.
What's 'ignore whitespace' actually doing?
When checked, the diff comparison normalises both inputs by stripping all whitespace before computing the LCS. Lines that only differ in indentation, trailing spaces, or line endings (LF vs CRLF) are reported as equal. The displayed text still preserves the original whitespace; only the comparison is whitespace-insensitive.
Can I diff JSON / YAML structurally instead of textually?
Not yet — this tool is line-based. For JSON, format both inputs first with json.tooljo.com (sorted keys, consistent indent) and then diff. That gets you most of the way to a structural diff without needing schema-aware comparison.
How does word-level highlighting work?
Within paired changed lines (lines that were 'replaced'), the tool runs a second LCS pass at word granularity to highlight only the bytes that actually changed. So in The quick brown fox → The QUICK brown fox, only quick → QUICK is highlighted, not the entire line.