Diff Checker
Compare text, code, and JSON with Myers' algorithm, inline char-level highlighting, and .patch export
A diff checker that uses the same algorithm Git uses— so inserting one line at the top doesn't mark everything below as changed. Switch between line, word, character, and JSON-semantic diff modes; view side-by-side or unified; drop a file into either pane. Modified lines show inline character highlighting so you see exactly which characters changed, not just the whole line. Everything runs in your browser.
Worked examples
Click any “Load” button to drop the example into the comparison fields above. Each example showcases when a different diff mode (line / word / character / JSON) is the right tool for the job.
Code review (JS function rewrite)
A function gains a parameter, a comment, and changed logic.
Inline highlighting will show the per-character changes inside each modified line — e.g. let → const inside the for loop.
JSON config diff
Two snapshots of a package.json showing dependency bumps and an added script.
Switch the mode dropdown to "JSON (semantic)" to ignore key ordering and whitespace, isolating real value changes from cosmetic ones.
Writing edit (prose revision)
A blog paragraph before and after a copy edit.
Word-mode diff is a good fit here — line-mode treats the whole paragraph as one changed line.
Config file change (dotenv)
A .env file with renamed keys and a new variable.
Line mode is the right choice for config files — each line is a meaningful unit.
SQL migration
An ALTER TABLE statement gains a column and a constraint.
Inline char highlighting makes it easy to spot the WITH TIME ZONE addition and the UNIQUE constraint on email.
Markdown documentation update
A README section with a new heading and a typo fix.
Markdown structural changes (new headings) are clearest in line mode; prose tweaks within a paragraph would benefit from word mode.
Related tools
Diff checker reference
How the comparison actually works under the hood, when to pick each diff mode, and the gotchas that catch people the first time they compare two files.
How the diff is computed
This tool uses Myers' diff algorithm via the jsdiff library — the same algorithm Git uses internally. Given two pieces of text, Myers finds the shortest edit script(the smallest set of insertions and deletions) that turns the first into the second. That's what makes the output feel right: insert one new line at the top of a file, and only that one line is highlighted as added, not every line that shifted down by 1.
Naive line-by-position comparisons (which most quick implementations still do) fail this test badly. They mark every line below an insertion as “different” even though those lines are unchanged.
Picking the right diff mode
| Mode | Granularity | Best for |
|---|---|---|
| Line | One row per newline | Code, config files, anything where each line is a meaningful unit. Default. |
| Word | One token per whitespace-separated word | Prose, blog posts, documentation. Highlights individual word edits that line mode would treat as “whole paragraph changed.” |
| Character | One row per character | Very fine-grained: spotting typos, single-character substitutions, ID changes. Generates lots of output for large inputs. |
| JSON (semantic) | Parses both sides as JSON first | JSON-vs-JSON comparison that ignores key ordering and whitespace differences. Surfaces only real value / structure changes. |
Side-by-side view also adds inline character-level highlightingwithin modified line pairs — so you see exactly which characters changed in a single line, even when the overall mode is “line.” This is the same UX touch that makes a diff feel sharp.
Side-by-side vs unified view
Original on the left, modified on the right. Easier scan for non-technical reviewers, and works well for large rearrangements where the modified content is far from where it used to be.
Git-style: one column, prefixed with + (added), - (removed), or space (unchanged). Compact, familiar to anyone who reads git diff or PR reviews, better for tight diffs where the change is concentrated in a few lines.
When developers reach for a diff checker
- Pre-PR self-review— paste your branch's file vs main to see exactly what you're proposing.
- Config drift — compare a production
.envor YAML against staging to spot environment-specific differences. - API response comparison — JSON mode handles two API responses where key ordering differs but values may have drifted.
- Schema migrations — comparing two versions of a SQL
CREATE TABLEstatement. - Document review — what changed between draft v3 and v4 of a contract / README / blog post.
- Log diffing — same query run twice; where did the responses diverge.
- Translation review — confirming that a translation of a UI string preserves placeholders and structure.
Privacy & limits
- The diff runs entirely in your browser — nothing is uploaded.
- File upload is capped at 1 MB per pane; larger files would freeze the UI while jsdiff runs.
- The Share permalink button encodes both inputs into the URL hash (base64url). Combined size cap is ~50 KB, after which the link is too long to be reliably pasted into chat / email.
- Copy as patch and Download .patch output the unified-diff format that
git applyunderstands.
Frequently Asked Questions
The diff algorithm, when to pick each mode, file upload, sharing, and the .patch format.