Compare two JSON documents and surface key, type, and value differences.
Understand the format
A structural comparison walks both documents key by key, so it reports meaningful differences instead of the line noise a text diff produces.
A text diff compares characters and lines, so reindenting a file or emitting keys in a different order produces a wall of changes that mean nothing. A structural diff parses both sides first and then walks the resulting values, reporting only differences that a consumer of the data would actually observe: a key present on one side, a type that changed, an array whose length differs, or a primitive value that is no longer equal.
This comparison reports each difference with a path such as $.items[0].qty, which reads the same way as the accessor you would write in code. That makes the output easy to translate into a fix or a test assertion.
Not every difference is a defect. Timestamps, request identifiers, and pagination cursors are expected to change between two captures. Type changes almost always matter: a number that became a string, an object replaced by null, or an array that collapsed into a single value will break strict consumers even when the visible value looks the same.
Key order is never a difference in JSON. If two systems disagree about ordering, that is a serialisation detail, not a contract change, and it is precisely the noise a structural comparison removes.
Step by step
Both documents are parsed and compared locally in the browser, so two production captures can be diffed without sending either one to a server.
Worked examples
Input
Left: {"total": 25} Right: {"total": "25"}Result
$.total: type mismatch (number vs string)
The rendered value is identical in a UI, but arithmetic and strict schema checks break downstream.
Input
Left: {"id": 3, "email": "a@example.com"} Right: {"id": 3}Result
$.email: missing on right
This is the signature of a removed field or a permissions change that now filters the attribute out of the response.
Reference
| Reported difference | Meaning | Typical severity |
|---|---|---|
| missing on left / missing on right | The key exists on one side only. | High when the field is required by a consumer. |
| type mismatch | The same path holds different JSON types. | High: strict parsers and typed clients fail here. |
| array length differs | Collections have a different number of elements. | Medium: often paging, filtering, or ordering. |
| value comparison | Same path and type, different primitive value. | Low to high depending on whether the field is volatile. |
Practical Guide
Troubleshooting
FAQ
No. JSON objects are unordered collections of members, so reordering keys produces no differences at all.
By index. Element zero on the left is compared with element zero on the right, so an inserted first element shifts everything and produces many differences.
No, and the distinction matters. A key with a null value exists and is explicitly empty; a missing key was never sent. APIs frequently assign different meanings to the two.
The comparison caps the reported differences so a completely unrelated pair of documents does not produce thousands of lines. Fix the top entries and run it again.
Yes, within the memory available to the browser tab. For multi-megabyte captures it is usually faster to narrow both documents to the subtree you actually care about.
Go deeper