JSON Compare

JSON Compare is a tool that finds the differences between two JSON documents by comparing their structure, not their text. You paste one document on each side and it reports exactly what changed: which keys were added, which were removed, and which values differ — each labelled with the full path to where it lives.

That matters because JSON is a tree of objects, arrays and values, not a sequence of lines. Two documents can look completely different as text yet be structurally identical, and vice versa. A structural compare parses both sides and matches them by meaning, so { "a": 1, "b": 2 } and { "b": 2, "a": 1 } are treated as the same object — because in JSON, object key order carries no meaning.

Everything happens in your browser. Both documents are parsed and diffed locally with JavaScript, so neither one is ever uploaded to a server. You can compare production payloads, secrets or customer data without it leaving your machine.

The obvious alternative is a plain text diff — pasting both documents into a line-based diff viewer or running git diff on two files. The problem is that a text diff does not understand JSON. It flags re-ordered keys, different indentation and trailing-comma style as "changes", burying the one real difference you care about under noise it invented.

A structural compare fixes this in three ways:

• It ignores formatting. Whitespace, indentation and key order never produce false positives, because the tool compares parsed values rather than characters.
• It reports by path. Instead of "line undefined changed", you get config.retry.maxAttempts: 3 → 5, which tells you precisely what moved and where.
• It respects JSON semantics. Object keys are matched by name and treated as unordered; array items are compared position by position, because array order is meaningful.

An online, browser-based tool also means there is nothing to install and nothing to trust with your data. You get the accuracy of a real JSON differ without a server ever seeing your input.

1. Paste the first document into the left panel. It is parsed as you type, so a syntax error is flagged immediately.
2. Paste the second document into the right panel — typically an old and new version of the same thing: two API responses, a config before and after a deploy, or expected vs actual test output.
3. Read the diff. Each difference is listed with a marker and a path:

• + user.roles[2]: "admin" — a value was added
• - meta.legacyId — a key was removed
• ~ active: true → false — a value changed

1. Start with the changes. The ~ entries are usually what you are hunting during debugging; additions and removals often explain why something changed — a new field appeared, or an old one was dropped.

If the two payloads come from different sources and you want them to look identical for a manual read too, run each through the JSON Formatter first — though the structural compare does not need matching formatting to work.

Debugging API changes. Capture a response before and after a code change and diff them to see exactly which fields the change touched — without eyeballing hundreds of lines.

Reviewing config drift. Compare a config file across two environments (staging vs production) or two points in time to catch a setting that silently diverged.

Verifying test output. Diff the expected JSON fixture against what your code actually produced. The path-based report points straight at the failing field instead of dumping two blobs side by side.

Auditing data migrations. Compare a record before and after a transform to confirm only the intended fields moved and nothing was quietly dropped.

Comparing third-party payloads. When an upstream provider changes their schema, a structural diff of two sample responses shows added and removed fields at a glance.

Validate before you compare. If one side is not valid JSON, there is nothing to diff. A quick pass through a formatter or validator confirms both documents parse before you look for differences.

Remember arrays are ordered. [1, 2] and [2, 1] are genuinely different, and the tool will report a change at each index. If order really does not matter for your data, sort both arrays consistently before comparing.

Do not expect re-ordered keys to appear. Because object key order is meaningless in JSON, a structural compare deliberately ignores it. If you want key order flagged, you actually want a text diff — but for JSON that is almost never what you need.

Diff small, focused subtrees when possible. If you only care about one part of a large document, paste just that subtree on each side. A tighter comparison is easier to read.

Keep sensitive data local. Because the whole comparison runs in your browser, you can safely diff payloads that contain tokens, PII or internal identifiers — nothing is transmitted.