JSON Compare

Two JSON documents can look almost identical and still differ in ways that are hard to spot by eye — an extra field, a boolean flipped, a number changed three levels deep. A JSON diff walks both documents key by key and array index by index, reporting exactly which paths were added, removed, or changed, instead of making you scan two walls of text for the one line that moved.

This matters most when comparing API responses across versions, config files across environments, or a request body against an expected fixture in a test. Key order in an object never changes its meaning, so this tool ignores it — only the actual keys and values are compared.

It runs entirely in your browser: both documents are parsed and diffed locally and never sent anywhere, so it is safe to compare a real API response or config containing internal data.

The result is a flat, readable list of paths — user.address.zip, items[2].price — each tagged as added, removed, or changed, with the old and new value shown inline. Copy the report as plain text to paste into a PR description or a bug report.

Arrays are diffed positionally, not by matching

Arrays are compared by index, not by matching similar objects together — this is the single most important thing to know when reading array diffs. If an array of objects gets reordered but no individual object actually changed, every index still shows as "changed", because the object now sitting at index 2 is being compared against whatever used to be at index 2, not matched up with its old self elsewhere in the array. That's not a bug in the diff — it's an accurate description of what changed positionally — but it can look alarming for a change that's really just a re-sort.

"1" vs. 1 — type changes count as real changes

A type change and a value change look similar but mean different things: the string "1" and the number 1 are different values in JSON even though they'd compare equal with loose equality in JavaScript, and this tool reports that as a real change — which matters most when comparing a response before and after an API started returning numeric IDs as strings, a change that's easy to miss by eye but breaks strict-equality checks downstream.

Null vs. missing keys

A key that's present with a value of null is reported differently from a key that's absent entirely — the former is a "changed" entry (old value to null, or vice versa), the latter is "added" or "removed". That distinction matters for APIs where a field being explicitly nulled and a field being omitted mean genuinely different things to the client consuming it.