On this page
To interpret differences between two JSON documents, apply three rules: JSON Diff ignores formatting whitespace and object property order, compares arrays by index, and distinguishes a missing field from one present with null. The tool interprets JSON values rather than comparing lines. Use these rules to predict each pair’s summary before trying it.
| What changes between inputs | How JSON Diff compares it | Expected result |
|---|---|---|
| Indentation, line breaks, or object key order | Matches properties by name and compares their values. | No differences if the values stay the same. |
| Array items | Matches each previous index to the same new index. | An insertion at the beginning can produce several changes and an addition. |
A missing field versus a field with null |
Checks whether the property exists as well as its value. | An addition when you add it; a removal when you delete it. |
Try the following pairs in JSON Diff, with the first input as the previous JSON and the second as the new JSON. Spaces inside a string belong to its value: "A B" and "AB" are different.
Same value, different text: why are there no differences?
Before:
{"a":1,"b":2}After:
{
"b": 2,
"a": 1
}The expected summary is 0 additions, 0 removals, and 0 changes: 0 differences total. Both inputs contain a with value 1 and b with value 2. Changing their presentation does not change those values.
A line-based text diff could flag the switch from one line to several, the whitespace, and the key order. A semantic comparison removes that noise when you want to know whether the data changed. JSON Diff does not offer a text diff view.
The object/array distinction comes from the format: RFC 8259, section 4 describes objects as unordered collections; arrays are ordered sequences under section 5. Matching items by index is this particular tool’s comparison rule.
Inserting at the start of an array: why are there three differences?
Before:
{"items":["A","B"]}After:
{"items":["X","A","B"]}The current version compares positions, starting at index 0:
| Path | Kind | Before → after |
|---|---|---|
$.items[0] |
Changed | "A" → "X" |
$.items[1] |
Changed | "B" → "A" |
$.items[2] |
Added | Missing → "B" |
The expected summary is 1 addition, 0 removals, and 2 changes: 3 differences total. The addition is "B" at the new index [2], even though you added "X" at the beginning.
The algorithm does not infer “X was inserted and the other items shifted.” It does not detect moves or match items by an id field either. Read each row as a difference between values at that position, rather than a history of edits.
Missing properties, null, and “null”: what is the difference?
Compare this previous input:
{}with this new input:
{"nota":null}The summary is 1 addition, 0 removals, and 0 changes: 1 difference total:
| Path | Kind | Before → after |
|---|---|---|
$.nota |
Added | Missing → null |
The property nota does not exist in {}. In the second input it exists and its value is null. Reversing the inputs produces a removal at the same path.
Now compare before:
{"nota":null}with after:
{"nota":"null"}The summary is 0 additions, 0 removals, and 1 change: 1 difference total:
| Path | Kind | Before → after |
|---|---|---|
$.nota |
Changed | null → "null" |
The property exists in both objects, but changes from the JSON value null to a four-letter string. Every snippet here is valid JSON: syntax validity and value equality answer different questions.
What an empty diff means and what it cannot establish
A completed comparison with no differences means the represented values compared equal under these rules. It does not establish identical original text or equivalent application behavior. To decide which changes are expected and which need a regression investigation, see the guide to comparing JSON API responses.
Numbers and limits: the tool uses JavaScript numbers, so very large or precise numbers can lose precision during parsing. It displays a warning when it detects that risk and does not offer arbitrary numerical precision. It requires strict JSON and rejects duplicate keys. Each input allows up to 1,000,000 UTF-16 code units and 200 nesting levels; comparison allows up to 1,000 change records and has a work budget. If a limit is reached, reduce the sample: a failed operation does not establish equality. The JSON Diff page lists the current limits.