JSON Diff

What this tool does

It compares two JSON documents structurally, not as text. It walks both trees at once and reports every difference with its path (contact.email, products[id=2].price), classified into four kinds: added, removed, changed and type change.

The practical consequence is that key order and indentation stop existing as differences, and what stays on screen is only what actually changed.

Everything happens in your browser: you can paste API responses containing real data without it leaving your machine.

How to use it

1. Paste the original JSON on the left and the one you want to compare on the right.
2. If either has a syntax error, you get the line, the column and what is missing.
3. Read the difference table. Tick also show what did not change to see the whole document.

Why a text diff does not work for JSON

This is the reason this page exists. A line diff — the kind Git, editors and this site’s own text comparer use — is excellent for code, and counterproductive for JSON:

These two documents are identical:

{ "name": "Ana", "age": 30 }

{ "age": 30, "name": "Ana" }

In JSON an object is an unordered set of key-value pairs. The specification says so and every parser honours it. But a text diff marks both whole lines as changed, because the characters sit somewhere else.

And the other way round: reformatting a file with jq or with your editor’s “format” button changes no data at all, and produces a diff of hundreds of lines.

The result is that as soon as JSON comes from two different sources — two environments, two API versions, an export and an import — the text diff is useless: everything shows as changed and you cannot tell what matters.

The array problem, and how it is solved here

This is the detail that separates a useful comparer from one that is not.

An array does have order, so the natural thing is to compare element 0 with 0, 1 with 1, and so on. That works until somebody inserts an element at the start:

// before
[ {"id": 1, "name": "Concha"}, {"id": 2, "name": "Bolillo"} ]

// after
[ {"id": 0, "name": "Cuernito"}, {"id": 1, "name": "Concha"}, {"id": 2, "name": "Bolillo"} ]

Comparing by position: element 0 “changed” from Concha to Cuernito, element 1 “changed” from Bolillo to Concha, and element 2 is new. Three differences, and none of them is true. All that happened was one insertion.

The fix is to match by identifier instead of by position. The tool automatically looks for a stable key among id, _id, uuid, key, slug, code, sku, email and name, and only uses it if two conditions hold:

• it is present in every element of both arrays,
• and its values are unique within each array.

If there are duplicates or it is missing anywhere, matching by that key would lie, so it falls back to positional comparison. When it is used you are told which key was chosen, and paths become products[id=0] rather than products[2] — which is also a path that still means the same thing tomorrow, when the order changes again.

You can switch it off in the options to see the contrast with your own data.

The type change, which is kept separate

When the same path holds 1 in one document and "1" in the other, it is not a value change: it is a type change, and it gets its own category and its own colour.

The distinction matters because it is rarely intentional. It almost always means one of three things:

• An API started returning numbers as strings, typically after changing ORM or serializer.
• A field went from null to 0, or the other way, and the consuming client distinguishes “no data” from “the data is zero”.
• A half-finished migration left some records in one format and some in another.

These are differences that break a client even though the value “looks the same” on screen. A text diff cannot tell them apart from any other change; here they stand out.

When this actually gets used

• Comparing an API response across two environments (local versus production, or before and after a deploy) to find the field that changed by accident.
• Reviewing a data migration: the dump from before against the one from after.
• Debugging an API contract when the client fails and the response “looks the same”.
• Comparing two configuration files, two package.json files, two translation exports.
• Auditing what a third-party integration changed between two runs.

The three syntax errors that show up most

They are things JavaScript accepts and JSON does not, and the tool names them explicitly instead of echoing the browser’s cryptic message:

The line and column come from a purpose-built analyzer, not from the JSON.parse message. The reason is concrete: every engine formats that message differently, and in current Chrome and Node two formats coexist, only one of which includes the position. A purpose-built analyzer returns the same thing in any browser, and it can also explain the error rather than describe it.