Why a JSON diff is different from a text diff
Two JSON documents can be identical in meaning but look completely different as text: keys in another order, different indentation, everything on one line. A plain text diff reports all of that as changes. This JSON diff parses both documents and compares their values, so you only see real differences, each labeled with its location as a JSON path.
Example
Left: {"id":1024,"name":"Wireless Mouse","price":24.99,
"tags":["usb","office"],"stock":{"warehouse":12}}
Right: {"name":"Wireless Mouse","id":1024,"price":22.49,
"tags":["usb","office","sale"],"stock":{"warehouse":12,"store":3}}Semantic differences (3)
~ $.price 24.99 → 22.49
+ $.tags[2] "sale"
+ $.stock.store 3The swapped id and name keys are not reported, because object key order has no meaning in JSON.
Reading the paths
$is the root of the document..nameis an object key; keys with special characters appear as["content-type"].[2]is an array index, starting at 0.+means added,−removed and~changed. A change of type, such as"42"to42, is reported as changed.- Long values are shortened to 100 characters, and the list shows at most 500 entries while its heading gives the full count.
Options explained
- Semantic JSON (on by default) – rewrites both sides with a two-space indent and keys sorted alphabetically at every level, so the highlighted lines in the two editors are not disturbed by formatting or key order. Files you open and the sample are rewritten automatically; after pasting or typing, untick and re-tick the box to rewrite both sides. Text that does not parse is left as typed.
- Ignore case – compares string values case-insensitively in the list, so
"Admin"equals"admin", and ignores letter case in the line view. Key names stay case-sensitive in the list. - Ignore whitespace – applies to the line view only, where indentation and runs of spaces no longer count as changes. The list of semantic differences never depends on formatting.
- View – besides the list of differences, the editors show both documents Side by side or Unified with changed lines highlighted, and Collapse unchanged folds long stretches without changes.
Two rules are fixed. Object key order is always ignored in the list, and arrays are always compared position by position: ["a","b"] and ["b","a"] are reported as two changed items, and an item inserted at the start of an array shifts every element after it. There is no option to ignore array order, so sort lists of tags or IDs the same way on both sides before comparing.
Strict parsing
Both sides must be strict JSON. Comments, trailing commas, single quotes and unquoted keys are not accepted: the header of that side shows Invalid JSON with the line number, the status bar gives the parser message, and the list of differences stays hidden until both sides parse. Fix the input first; the JSON validator and JSON fixer help with that.
Numbers, nulls and missing keys
Values are compared exactly as JSON defines them. 1 and 1.0 parse to the same number and are equal, while null and a missing key are different: a key that exists with a null value on one side and is absent on the other is reported as added or removed. Very large integers beyond about 9 × 1015 lose precision when parsed in JavaScript, so two IDs that differ only in their last digits may compare as equal; compare such values as strings if that matters.
When to use a JSON diff
- API testing – compare a response against the expected fixture, or the same endpoint in staging and production.
- Configuration – see what changed between two versions of
package.json,tsconfig.jsonor a feature-flag file. - Data migrations – verify that exported records match after a transformation.
- Debugging – find which field differs between a working and a failing request payload.
For large documents, format them first with the JSON formatter if you also want to read them. Both documents are compared in your browser and never uploaded.