JSON Diff Checker
Compare API responses, config versions, and test fixtures without uploading either document to a server.
- Paste the original JSON on the left and the changed version on the right.
- Review added, removed, and changed lines in the generated diff.
- Format both documents first when structural changes are hard to read.
This tool runs entirely in your browser. Your JSON is not uploaded, stored, or logged.
Compare readable versions
Two responses can represent the same data while looking nothing alike on one line. Format both sides first so whitespace noise does not hide a real field change, then run the diff.
This is especially useful when debugging a failing integration: keep a known-good payload, paste the failing body beside it, and inspect the first meaningful difference instead of reading two minified blobs by eye.
Reading a JSON diff without being misled
Key order is not part of JSON semantics — the same object written in a different order is the same object — but a line-based diff still marks the whole region as changed when the order moves. When that noise buries the signal, sort the keys before comparing and read the diff again.
Types are the other trap. 1 and 1.0 look different and are the same number to most parsers, while 1 and the string 1 look almost identical and are not. When a field fails validation downstream with no visible value change, check whether its type changed rather than its value.
Three comparisons worth keeping
A diff earns its place when you deliberately keep a baseline around to compare against. The three that pay for themselves:
- Known-good response against the current failure — the first meaningful difference is usually the cause.
- Staging config against production config — catches the value somebody changed in one environment only.
- Before a deploy against after it — separates your change from an upstream API change.
- And when a diff comes back empty, confirm both sides are valid JSON first: an error body on one side compares surprisingly cleanly against a short real payload.
Why array diffs explode
Objects diff by key, so adding a field marks one line. Arrays diff by position, so inserting an item at the front shifts every later item and a line-based diff marks the whole tail as changed. A one-element addition to a hundred-item list looks like a hundred edits.
Two habits contain the noise: compare keyed collections after sorting both sides by their identifier, and read a large diff on an array as a single insertion rather than many changes. When order itself is the thing under test, keep it and read the result as a reordering instead of a rewrite.
Frequently asked questions
Should I format JSON before diffing?
Yes, when either side is minified or inconsistently indented. Formatting makes structural edits easier to see and reduces false noise from whitespace-only changes.
Is either document uploaded?
No. Both sides are compared in your browser. Tokens and customer fields stay on your device.
Why does adding one array item change every line in the diff?
Arrays are compared by position. Inserting near the top shifts every later item, so each one reads as changed. Sort both sides by an identifier, or read the diff as a single insertion rather than many edits.