A JSON diff compares two JSON documents structurally — by their parsed data, not their text. That distinction is the whole point: two documents can be textually different (different key order, different indentation, different escaping) while being semantically identical. A text diff like git diff will drown you in whitespace noise; a structural diff tells you what actually changed: which keys were added, which were removed, and which values differ.

Typical uses: comparing API responses between staging and production, checking what a deploy changed in a config file, verifying that a data migration preserved every field, and debugging why two supposedly identical payloads behave differently. The comparison runs entirely in your browser — both documents stay on your machine.

Both inputs are parsed into trees, then the trees are walked in parallel. At each path, the differ classifies the outcome: identical (values match), changed (both sides have the key but values differ), added (only in the right document), or removed (only in the left document). Nested objects are compared recursively, so a change deep inside an object is reported at its exact path rather than flagging the whole object as different.

Because comparison happens after parsing, formatting differences vanish: {"a":1,"b":2} and a pretty-printed version with keys in the opposite order compare as identical objects. This is exactly what you want when comparing an API response you formatted against a raw one from a log.

Objects are unordered in JSON, but arrays are ordered by definition — [1,2] and [2,1] are genuinely different values. A structural differ therefore compares arrays element by element by index. This has a practical consequence: if your API returns list items in nondeterministic order (a common result of SQL queries without ORDER BY), the diff will report many changes that are really just reordering.

When that happens, the fix is to normalize before diffing: sort both arrays by a stable key (like id) on the producing side, or use the JSON Sort Keys tool for objects. If two diffs of the same endpoint keep showing spurious array changes, treat it as a signal that the API's ordering is unstable — that is worth fixing at the source, since it also breaks HTTP caching and pagination.

Start with removed keys — they break consumers most often, because code that reads a missing property gets undefined and fails somewhere far from the actual cause. Then review changed values, paying attention to type changes (the string "42" versus the number 42 is one of the most common breaking changes between API versions, and one many eyes skip over). Added keys are usually safe for consumers but confirm they are intentional; accidentally leaking new fields is a classic way internal data escapes into public APIs.