Diff Checker_
A diff checker built the way developers read diffs: side-by-side panes with line numbers on both sides, gap markers where lines were inserted or deleted, word-level highlights inside changed lines, and a unified view with real @@ hunks and a context control. Copy the result as a git-style patch.
Every comparison happens in this tab — the diff engine makes no network calls, which the security policy enforces and the test suite asserts. The big diff sites answer confidentiality with a paid offline desktop app; here the browser tab is the offline app.
A diff checker that reads like the tools you already use
Reading the side-by-side view
The split view is an instrument panel: old version left, new version right, each with its own line-number gutter. Rows stay aligned across the panes — when a line exists on only one side, the other side shows a hatched gap marker, so insertions and deletions never shift the two files out of step visually. When an old line and a new line correspond, the engine pairs them and re-diffs the pair at word level; the bright inline marks are the exact tokens that changed, which is the difference between spotting a renamed variable in one glance and reading two forty-character lines character by character.
The unified view, and why patches look like that
The unified view is the format of git diff, code review, and every patch file since the 1970s: one column, - rows from the old file, + rows from the new, a few unchanged context lines around each change, and an @@ header locating every hunk. This online diff checker gives you the same format with a context control (1, 3, or 8 lines, or the whole file) — and the Copy Patch button emits it as text, so the reference table below doubles as the legend for what you're pasting into a ticket.
Diffing JSON, files, code, and PDFs
The variants people search for mostly reduce to preparation. A json diff checker works far better on normalized input: run both documents through the JSON formatter with sorted keys first, and key-order noise disappears from the diff. A file diff checker is the Upload buttons — both files are read locally, and line endings are preserved exactly as they are on disk. Code diffs work as-is (that's the home turf), though minified files should be beautified first. And a pdf diff checker is honestly a different machine: extract the text, then diff the text here — comparing PDF layout and graphics is what the commercial tools' paid tiers are for.
Where the diff runs, and why that's checkable
If you searched for the well-known diffchecker com site: its free tier runs online with server-side save and share, and its answer for proprietary code is Diffchecker Desktop — a paid application whose pitch is that files never leave the device. That pitch is the right one; the pricing is the difference. This page's engine is plain JavaScript running under a Content-Security-Policy that forbids outbound requests from tool code, so "never leaves the device" isn't a product tier here — it's a property you can verify by opening devtools' network tab, or by pulling your network cable and diffing anyway.
How to use
- 01Paste the old version on the left and the new on the right — or use the Upload buttons for files. This diff checker tool compares live, and the stats line reports modified, added, and removed line counts as you type.
- 02Pick your view: Side_by_side for reviewing a code diff with aligned line numbers and gap markers, Unified for the patch-style single column. On narrow screens the unified view is the default; both stay available everywhere.
- 03Tune the comparison: Ignore whitespace for re-indented code, Ignore case where capitalization is incidental, and the Context select to widen or narrow how much unchanged code each hunk shows.
- 04Copy_Patch puts a git-style unified diff on your clipboard; Download saves it as diff.patch. Both carry every hunk even when a huge diff is trimmed on screen.
Four diffs from a developer's week
Snippet review without a repo
A teammate pastes a revised function in chat. Drop both versions in and the split view shows the rename and the changed guard clause in one look.
function retry(count) {
if (count > 3) throw new Error();
}function retry(attempts) {
if (attempts >= MAX_RETRIES) throw new Error();
}Config drift between environments
Staging works, production doesn't. Diff the two config dumps; the gap markers show what production is missing entirely, not just what differs.
12 pool_size = 20 │ 12 pool_size = 50 13 retry_on_fail = 1 │ ░░ (gap)
1 modified · 1 removed
Patch handoff in a ticket
No shared branch, but the fix needs review. Copy_Patch produces a unified diff any developer (and git apply) can read.
@@ -14,7 +14,7 @@ retries = 3 -timeout = 30 +timeout = 90 backoff = exponential
Ticket comment, review thread, or git apply
Lockfile sanity check
An install changed more than expected. Diff old and new lockfiles with context 1 — hunk headers list exactly which packages moved.
View: Unified · Context: 1 line
@@ -1041,3 +1041,3 @@ - "left-pad": "1.3.0" + "left-pad": "1.3.1"
Reading a unified diff
| Element | Example | Meaning |
|---|---|---|
| Hunk header | @@ -3,5 +3,6 @@ | This hunk starts at line 3 in the old file spanning 5 lines, and line 3 in the new file spanning 6 |
| Removed row | -timeout = 30 | Present in the old file, gone from the new |
| Added row | +timeout = 90 | Present in the new file only |
| Context row | retries = 3 | Unchanged; included so humans (and patch tools) can anchor the change |
| Adjacent − then + | -old line / +new line | An edit: the same logical line before and after — this page also word-highlights the pair |
| Multiple hunks | two @@ headers | Changes far enough apart that their context windows don’t touch |
The counts in the header include context rows — that’s why -3,5 +3,6 can describe a one-line edit plus one added line with three lines of context around them.
Which view for which job
| Job | Use | Why |
|---|---|---|
| Reviewing changes line by line | Side_by_side | Aligned gutters and gap markers keep both versions in visual lockstep |
| Pasting a change into a ticket or review | Unified + Copy_Patch | The @@ format is what git, reviewers, and patch tools all speak |
| Scanning a huge diff for hotspots | Unified, context 1 | Minimal context compresses the diff to just the changes and their addresses |
| Understanding one dense change | Side_by_side | Word-level marks inside the pair beat re-reading two long lines |
| “Are these even different?” for prose | the Text Compare page | Its verdict-first design answers same/whitespace-only/case-only in one line |
Rule of thumb: side-by-side to understand, unified to communicate.
Tips & best practices
- Diff JSON after normalizing it — format both sides with sorted keys in the JSON formatter, and the diff shrinks to the values that actually changed.
- Beautify minified code before diffing: a one-line bundle diffs as one giant modified pair, which tells you nothing. Formatted first, the change becomes a three-line hunk.
- Context 1 is the fastest way to audit a large diff; context 8 or All is for understanding an unfamiliar change in its surroundings.
- Upload files instead of pasting when line endings matter — the upload path preserves CRLF exactly, while pasting into any browser textarea silently normalizes it.
- A patch that says “everything changed” usually means line endings or indentation flipped — check with the toggles off first, then decide whether the whitespace change was intended.
- The patch you copy here applies with git apply if the left side matches the file on disk — handy for shipping a quick fix without a branch.
Gotchas — how diffs deceive
Ignore-whitespace can hide real changes
In YAML, Python, and Makefiles, indentation is semantics — an outdented block is a different program that a whitespace-ignoring diff calls identical. Run those files with toggles off; treat “only whitespace changed” as a finding, not noise.
Moved blocks read as delete + add
Line diffs have no concept of “moved”: relocate a function and it appears as a removal at the old site and an addition at the new one. Before concluding code was deleted and rewritten, check whether the − and + blocks are the same lines in a new place.
A line-ending flip diffs the whole file
Convert CRLF to LF and every single line technically changes. This page compares uploaded files byte-accurately and tells you when line endings are the only difference — before you scroll through a thousand phantom changes.
Minified and single-line files diff uselessly
One 80KB line versus another 80KB line is one “modified pair” — and past the word-refinement limit, no inline marks either. The diff isn’t wrong; the input is unreadable. Beautify both sides first, then diff.
Sharing-enabled diff sites keep what you share
A share link means your code went to a server and has a URL now — the leading site’s own confidentiality answer is its paid offline desktop app. Proprietary code belongs in a diff tool that has no upload path at all.
Technical details
- Views
- Side-by-side (aligned rows, per-side gutters, gap markers) · Unified (@@ hunks, dual gutters, context 1/3/8/All); default follows screen width, your choice sticks
- Engine
- Shared diff module with text-compare: line-level LCS (patience anchoring, exact-DP core, bounded worst-case fallback), word-level refinement on modified pairs up to 2,000 chars
- Options
- Ignore whitespace (trim + collapse) and ignore case — comparison keys only; displayed text is never altered
- Patch output
- Git-style unified diff, 3-line context, via Copy_Patch or diff.patch download — complete even when the on-screen view is trimmed
- Line endings
- Uploads bypass textarea normalization, so CRLF/LF differences are detected and reported instead of silently erased
- Limits
- 500,000 characters per side, explicit message beyond; views render the first 2,000 rows with a note
- File handling
- Both Upload buttons read through the local File API — there is no upload endpoint and no share-link machinery to leak through
- Network use
- Zero requests while diffing: blocked by the Content-Security-Policy, asserted by the test suite, verifiable with the network tab or cable unplugged
Frequently asked questions
Does my code get uploaded when I diff it here?
No — the engine runs in your tab and the site’s Content-Security-Policy forbids tool code from making network requests, which the automated tests assert. You can verify it yourself: open the browser’s network tab while diffing, or go offline and keep working.
What does @@ -3,5 +3,6 @@ mean?
It locates a hunk: starting at line 3 of the old file covering 5 lines, and line 3 of the new file covering 6. The counts include unchanged context rows, which is why they rarely match the number of +/− lines. The full legend is in the unified-diff table above.
Can I apply the copied patch with git?
Yes — the output is a standard unified diff. Save it (or pipe the clipboard) and run git apply; it succeeds as long as the left side matches the target file. For review threads and tickets, paste it as-is.
How do I diff two JSON files meaningfully?
Normalize first: format both through the JSON formatter with sorted keys and identical indentation, then diff. Otherwise key order and formatting differences drown the real value changes.
Why does the whole file show as changed?
Usually an invisible global change: line endings flipped (CRLF↔LF), indentation converted between tabs and spaces, or the file was reflowed. Upload the files (uploads preserve endings exactly) and check the stats line — it names a pure line-ending difference outright.
Can it diff Word documents, PDFs, or images?
Not directly — this is a text instrument. Extract the text (most PDF readers and Word itself can) and diff that. Visual PDF and image comparison is genuinely different machinery, which is why commercial tools sell it as a separate paid feature.