Diff Checker
Compare two blocks of text or code side-by-side to find every difference with word-level highlighting and synchronized scrolling.
TL;DR
Paste an original on the left and a changed version on the right. This tool runs the same family of algorithm as git diff — the Myers diff algorithm — which finds the shortest edit script turning one text into the other. Use line granularity for code and configs, word granularity for prose and contracts, and charactergranularity to hunt typos, trailing spaces, and tabs-vs-spaces. Green means added, red means removed; a "changed" line is just a removal and an addition shown on the same row. Everything runs in your browser — nothing is uploaded.
What the Myers algorithm actually does (and why git uses it)
Eugene Myers published "An O(ND) Difference Algorithm and Its Variations" in 1986. It is the default engine behind git diff, diff -u on most systems, and the comparison view in GitHub, GitLab, and VS Code. The problem it solves is precise: given an original sequence and a new one, find the shortest edit script — the smallest set of insertions and deletions — that converts the first into the second.
It works by treating the two inputs as axes of a grid and searching for the longest common subsequence (LCS). A diagonal step means "this element is unchanged"; a horizontal step is a deletion; a vertical step is an insertion. Myers finds the path with the fewest non-diagonal steps. The complexity is O(N·D) where N is the total input size and D is the number of differences — so when two files are nearly identical (small D), it is extremely fast, which is exactly the common case in version control.
The practical consequence: Myers minimizes the number of edits, not necessarily the most human-readable grouping. That is why git ships an alternative --diff-algorithm=patience (and histogram) — they sometimes produce diffs that line up better for humans, at the cost of speed. This tool uses the classic Myers approach because it matches what you already see in git diff, so a difference here is the difference your reviewer will see in the pull request.
Line vs word vs character diff: which granularity to pick
The single biggest mistake people make with diff tools is using line granularity on a one-paragraph contract, then squinting to find the word that moved. Granularity decides what counts as a single "token" the algorithm compares. Pick it from the table below.
| Granularity | Compares | Best for | Avoid when |
|---|---|---|---|
| Line | Whole lines (split on newlines) | Source code, YAML/JSON configs, CSV, logs, SQL migrations — anything where the line is the unit of meaning | Long paragraphs where one word changed; you will see the whole line marked changed |
| Word | Words (split on whitespace) | Contracts, essays, marketing copy, documentation, translated strings — reflowed prose | Minified code or single long tokens; word boundaries become meaningless |
| Character | Individual characters | Typos, a single changed digit in an API key, trailing whitespace, tabs vs spaces, smart quotes vs straight quotes | Large files; output becomes a noisy mosaic of single-char highlights |
Rule of thumb: this tool defaults to word granularity, which compares whole lines and then highlights the exact changed words inside each modified line. Switch to line when you only care which whole lines changed, and to character when you suspect an invisible difference such as a trailing space or tab.
Reading added / removed / changed markers correctly
Diff markers are a tiny language, and they trip people up because there is no native "changed" operation — only add and remove. Here is how the markers in this tool map to git diff output you have seen in the terminal.
| You see | git diff sign | What it means |
|---|---|---|
| Green / addition | + | A line (or word/char) exists only in the right-hand / new version. |
| Red / removal | - | A line exists only in the left-hand / original version. |
| Red + green pair | - then + | A "changed" line: the original removed and the new one added. The inline highlight shows the exact words/chars that differ. |
| No color | (blank space) | Context: the line is identical in both versions (a diagonal step in Myers' grid). |
| Hunk header | @@ -a,b +c,d @@ | In unified view: lines a–b of the original align with lines c–d of the new file. |
Three places a diff checker earns its keep
1. Code review before the pull request
Paste the main version of a function and your local edit. Because this uses Myers like git does, the highlighted hunks match what your reviewer will see on GitHub — so you can catch an accidental whitespace reformat (which balloons the diff) before you push. Tip: if a one-line logic change shows as a 40-line diff, an editor auto-format reflowed the file. Revert the formatting, keep the logic change.
2. Contract and document comparison
Legal redlines are the original use case for diff. Switch to wordgranularity, paste the previous clause and the counter-party's revision, and every changed term lights up — including the sneaky ones like "shall" becoming "may" or a 30-day window becoming 45. Word-level avoids the line-diff trap where reflowed paragraphs mark dozens of unchanged lines as different.
3. Configuration drift between environments
"It works in staging but not production" is usually config drift. Paste both nginx.conf files, or both .env files, at line granularity and turn on hide unchanged lines. The remaining handful of differences — a missing worker_connections, a flipped feature flag, a stale database host — are your root cause. Character granularity is the follow-up when a value looks identical but a trailing space or smart quote sneaked in.
Diff checker questions people actually search
Why does a one-word change mark the whole line as different?
Because you are at line granularity, where the entire line is one token: change anything in it and the whole line counts as removed-then-added. The fix is to switch to word granularity (this tool's default), which still pairs the lines but then highlights the exact changed words inside each modified line. That also keeps reflowed prose from flagging dozens of untouched lines as different.
Is this the same diff algorithm git uses?
Yes — it is the Myers diff algorithm, the default for git diff and most diff -u implementations. Git also offers patience and histogram algorithms (via --diff-algorithm=) that can group changes more readably in edge cases, but the default Myers result is what you see in a standard pull request, which is what this tool reproduces.
Two values look identical but the tool says they differ. Why?
An invisible character. The usual suspects: a trailing space, a tab where the other side has spaces, a Windows \r\n line ending vs a Unix \n, a non-breaking space (U+00A0) pasted from a webpage, or a smart quote ("curly quote") vs a straight quote. Switch to character granularity and the offending character will be the only thing highlighted.
What is the difference between split view and unified view?
Split view shows the two versions side by side in separate columns with synchronized scrolling — best for reading two complete documents at once. Unified view stacks additions and removals in a single column with +/- markers, exactly like terminal git diff output — best for compact change-tracking and for pasting into a chat or issue.
Can I compare two JSON objects or formatted code reliably?
Diff is line-based, so cosmetic differences (key order, indentation, spacing) will show up as changes even when the data is equivalent. For a meaningful comparison, normalize both sides first — run each through the JSON Formatter with the same indentation, then diff the results. That isolates real value changes from formatting noise.
Is my code or document uploaded anywhere?
No. The site is a static export with no backend, and the entire comparison runs in your browser's JavaScript engine. You can confirm in DevTools → Network: clicking compare triggers zero outbound requests. That makes it safe for proprietary source code, unreleased contracts, and configuration files containing secrets.