How the comparison works
Both inputs are parsed as JSON and compared structurally, value by value. Each difference is reported with a JSONPath-style location such as $.settings.theme or $.roles[1]. Keys that are not plain identifiers are quoted, for example $["first name"].
| Change | Meaning |
|---|---|
| Added | The key or array element exists only in the changed document. |
| Removed | The key or array element exists only in the original document. |
| Changed | Same type in both documents, different value (e.g. "dark" → "light"). |
| Type changed | The JSON type differs, e.g. the number 42 became the string "42", or null became an object. These often indicate API contract changes. |
Rules worth knowing
- Object key order is ignored.
{"a":1,"b":2}and{"b":2,"a":1}are equal. - Arrays are compared by position. Element 0 is compared with element 0, and so on. If an item is inserted at the start of a list, every following position is reported as changed. This matches how ordered lists behave in most APIs, but it is not a set comparison.
- A missing key is different from
null.{}versus{"a": null}is reported as an added key. - Numbers are compared by value.
1,1.0and1e0are equal, because they parse to the same number. Integers beyond JavaScript's safe range may compare as equal after rounding.
Typical uses
- Checking what changed in an API response between two releases or environments.
- Reviewing configuration changes (feature flags,
package.json, infrastructure settings). - Debugging snapshot test failures where the text diff is noisy because of formatting.
Copy report produces a plain-text summary (+ added, - removed, ~ changed) suitable for pasting into a pull request or ticket. If one of the inputs is invalid, fix it first; the JSON Formatter shows the exact error location.
Comparing JSON on the command line
# Normalise both files with jq, then use a regular diff
diff <(jq --sort-keys . a.json) <(jq --sort-keys . b.json)