JSON Diff

Compared by path, not by line

A plain text diff would flag every reformatted line, even when the data is identical. This tool parses both sides and flattens them to dotted key paths — user.address.city, items[0].price — then compares those paths. Reorder the keys or change the indentation and the result stays the same; only real value differences show up.

Each row is marked + added, − removed, or shown as a remove/add pair when a value changed.

A small diff, read out

// left                  // right
{ "name": "Ada",        { "name": "Ada",
  "role": "admin",        "role": "editor",
  "active": true }        "active": true,
                          "team": "core" }

A structural diff reports three things: role changed from "admin" to "editor", team was added with value "core", and name and active are unchanged. It does not care that active sits on a different line on each side — only the data is compared.

Everyday uses

• API debugging — see which fields differ between two responses, or between staging and production.
• Config drift — compare a working config against a broken one to find the setting that moved.
• Snapshot tests — understand why a saved snapshot no longer matches current output.
• Migrations — confirm a transform changed only the fields you expected.

The diff you see, and the one Git does

Comparing two objects is a two-way diff: here's the left, here's the right, here's what moved. It's perfect for "what changed between these two API responses". Merging is a harder, three-way problem, and it's what Git does behind a conflict: it looks at your version, their version, and the common ancestor all three changed from, so it can tell an edit you made from an edit they made. That's why a plain two-way comparison can't resolve a merge on its own — without the ancestor it has no way to know which side actually introduced a change versus which side just kept the original.

When you need to describe a change rather than just look at it, there are standard formats for that. JSON Patch (RFC 6902) writes a change as a list of operations — add, remove, replace at a given path — which is how a lot of REST APIs accept partial updates. JSON Merge Patch (RFC 7386) is the simpler cousin: send a small object shaped like the original, where a key set to null means "delete this". Knowing which one an API expects saves a lot of guesswork when a PATCH request quietly does nothing.

Real situations this saves you in

The everyday win is regression testing. Capture a known-good API response, run the request again after a change, and diff the two — anything that shifted is either the fix you intended or a bug you just shipped. The same move catches config drift: dump the configuration from staging and production side by side, and the diff is the short list of settings that explain why one environment behaves and the other doesn't. It also makes code review of generated files bearable, since a structural diff ignores the reformatting and key reordering that a line-based diff would drown you in.