Do different object key orders show as a diff?

No. Both sides are sorted before comparing, so semantically identical objects diff to zero.

How are arrays handled?

Arrays are order-sensitive — `[1,2,3]` vs `[3,2,1]` shows all three positions as changes.

Parsing errors surface immediately. It is safer to validate each side with the json-formatter tool first.

Example

Left:  {"name":"yutils","version":"0.1.0","tools":50}
Right: {"name":"yutils","version":"0.2.0","tools":55,"new":true}

  "name": "yutils"
- "version": "0.1.0"
+ "version": "0.2.0"
- "tools": 50
+ "tools": 55
+ "new": true

Keys are sorted before comparing, so object-key order differences do not show up as diffs. Arrays compare positionally by index.

Usage / FAQ

Q.Do different object key orders show as a diff?: A.No. Both sides are sorted before comparing, so semantically identical objects diff to zero.
Q.How are arrays handled?: A.Arrays are order-sensitive — `[1,2,3]` vs `[3,2,1]` shows all three positions as changes.
Q.What if my JSON is invalid?: A.Parsing errors surface immediately. It is safer to validate each side with the json-formatter tool first.

Fun facts

JSON Patch (RFC 6902, 2013) is the standard for unambiguously describing changes to a JSON document — an array of 6 operations (add / replace / remove / move / copy / test). It's most commonly used as the body format for HTTP PATCH (RFC 5789).
RFC 6902 (2013)
JSON Merge Patch (RFC 7396, 2014) takes a different approach — the patch *is* a new JSON document. `null` signals deletion, objects are merged recursively. It's intuitive, but it can't express 'set a property to null,' which is why the two standards (6902 vs 7396) end up serving different use cases.
RFC 7396 (2014)
The split — 6902 is path-based and more expressive (array index ops, atomic test), while 7396 is a recursive merge and simpler. The same edit becomes `[{op:"remove", path:"/a/b"}]` in one and `{a: {b: null}}` in the other. That's why different APIs pick different sides.
Wikipedia — JSON Patch