JSON Diff / Comparator

How to use JSON Diff / Comparator

1. Paste the original document into the left panel.
2. Paste the version you are comparing against into the right panel.
3. Read the added, removed and changed counts, then work down the list of paths — it updates as you edit either side.
4. Both inputs must be valid JSON; a syntax error on either side stops the comparison rather than producing a partial result.
5. A top-level array is compared as a single value, so wrap arrays in an object if you need per-key detail.
6. Nothing is uploaded — both documents stay in the page, which matters when you are comparing production payloads.

Formatting and key order are invisible to it

Both sides are parsed before anything is compared, so indentation, line endings, trailing commas in your editor and the order the keys happen to appear in never show up as differences. That is the whole reason to use a structural diff: run two versions of the same API response through a text diff and you will spend most of your attention on lines that only moved. Here, if the data is the same, the result says so.

How nesting is handled — and how arrays are not

The comparison recurses into nested objects, so you get precise paths like user.address.city rather than a note that “user changed”. Arrays are treated as single values: change one element of a fifty-item list and you get one changed row showing both arrays in full, not an element-by-element diff. This is a deliberate limitation — diffing arrays properly means guessing whether an item was edited, inserted or moved, and guessing wrong is worse than not guessing. For array-heavy payloads, compare a single element at a time, or sort both sides by a stable key first.

Reading the output

A green + is a key present only in the second document, a red − is one present only in the first, and an amber ~ is a key in both whose value differs, printed as old → new. Keys that match are counted in the summary but left out of the list, so a long document with one change produces one line. A type change — the string “1” becoming the number 1 — shows as a change, which is usually the bug you were looking for.

What people use it for

Catching an API regression between staging and production. Finding configuration drift between two environments that are supposed to match. Confirming that a data migration touched only the fields it was meant to. Reviewing what a dependency update did to package.json or tsconfig.json. Checking that a refactor left a serialised payload unchanged.