Compare two JSON documents by structure, not by line.
What it's for
See what actually changed between two versions of a JSON document — a config file, an API response, a saved record — by comparing the data rather than the text.
Before you start
Have both versions to hand: the older one and the newer one. They are compared in your browser and nothing is sent anywhere.
Paste the older version
Replace the sample in Before with the earlier document.
Paste the newer version
Replace the sample in After with the later one. The order matters only for the wording: something in After but not in Before counts as added.
Compare
Press Compare. The count at the top also updates as you type, so you can edit either box and watch the differences come and go.
Read the list
Under What changed, each entry names the field — such as salary, or tags[1] for the second item of a list — then its old value after − and its new value after +.
Reading the result
If it goes wrong
A text diff on JSON answers the wrong question. Change the indent, sort the keys, minify it — and a line diff reports that every line changed while the data is identical.
So the comparison is structural: both sides are parsed and the tree is walked by PATH. users[2].salary changed, wherever either sat in the file.
Key order is not a difference; array order is. That is the one judgement call here, and it follows what the two things actually are: a JSON object is an unordered set of members, an array is a sequence.
And 1.0 against 1 is the same number and a different document. It is listed separately — hiding it loses a real difference, calling it a change overstates one.
Because a text diff on JSON answers the wrong question. Reformat a document — change the indent, sort the keys, minify it — and a line diff reports that every line changed while the data is identical. Swap two keys and it reports two deletions and two insertions when nothing changed at all. This compares the parsed structure by path, so it sees what actually differs.
Because that is what the two things are. A JSON object is an unordered set of members, so {"a":1,"b":2} and {"b":2,"a":1} are the same object and any parser will hand your code the same result. An array is a sequence, so [1,2] and [2,1] are genuinely different. A differ that treats both the same is wrong in one direction or the other.
That one side has 1.0 where the other has 1, or 1e3 where the other has 1000. Those are the same number and a different document. Hiding it would lose a real difference between two files; calling it a change would make a reformat look like a data change. So it is listed separately and dimmed, and you can dismiss it at a glance.
Because it is usually the more serious kind. A number becoming a string, or a value becoming null, breaks the code reading it in a way a changed value does not — the consumer was not expecting a different shape. It is worth noticing before the changed values are.
Duplicate keys are legal JSON and every parser keeps the last one, so that is what gets compared — the value your code would actually see. The JSON Formatter reports duplicates if you want to find them.
Yes. Both sides are compared as they were written rather than through a floating-point value, so two 19-digit integers differing in the last place are still two different values. A differ using JSON.parse would round both to the same number and report no change.
A number becoming a string, or a value becoming null, breaks the code reading it in a way a changed value does not. The consumer was not expecting a different shape.
Important
Runs entirely in your browser; nothing is transmitted. This compares data, not text — indentation, key order and number formatting are invisible to it by design. Use Text Comparison when the bytes are what matter. Nothing you type here is sent to our servers — the calculation runs entirely in your browser.
