JSON Diff Checker
Compare two JSON documents and see exactly which keys were added, removed, or changed, with the full path to each — free and instant.
Comparison is by structure and value, not by text — reformatting, re-indenting, or reordering object keys never counts as a difference.
The colored line-by-line view below is generated by re-printing both documents with sorted keys and consistent indentation first, then diffing that — so it inherits the same "formatting never matters" guarantee as the summary above it.
Arrays are compared index by index: changing the order of array items shows as changes at each shifted position, not as a "moved" item.
A key present in only one document shows as added or removed; a key present in both with a different value (or a different type entirely) shows as changed.
Numbers are compared by value, so 1 and 1.0 are treated as identical.
| Path | Status | Before | After |
|---|---|---|---|
| version | changed | 1 | 2 |
| tools[2] | added | — | "case-converter" |
The comparison runs entirely in your browser as you type — neither document is ever uploaded to a server.
Key order never counts as a difference — {"a":1,"b":2} and {"b":2,"a":1} are treated as identical, since JSON objects have no defined order.
Checking what an API response actually changed between two calls, or verifying a config file edit only touched the keys you intended.
How it works
What a JSON diff checker actually compares
A JSON diff checker answers a more specific question than a plain text diff: do these two documents represent the same data, regardless of how they happen to be formatted? Two JSON documents can look completely different as text — different indentation, different key order, extra whitespace — while representing exactly the same underlying data. A structural comparison like this one sees past all of that and reports only real differences in the data itself.
Structural comparison versus text comparison
If you ran these two documents through a plain text diff, they would look totally different:
json
{"name":"Alice","age":30}
json
{
"age": 30,
"name": "Alice"
}
Every line differs. But structurally, they are identical — same keys, same values, just reformatted and reordered. This tool parses both documents first and compares the resulting data, so key order and formatting never register as a difference. It reports zero differences for the pair above, which is the correct answer for anyone asking "did the data change?"
Reading a path
Every difference in the table is located by its full path from the document root, using two conventions together:
- Dot notation for object keys:
user.address.citymeans thecitykey, inside theaddresskey, inside theuserkey. - Bracket notation for array indexes:
items[2]means the third element (index 2) of theitemsarray.
The two combine for nested structures — users[0].roles[1] is the second role of the first user. A difference at the very top level, where the whole document is a different type or value, is labeled (root).
The three kinds of difference
| Status | Meaning |
|---|---|
| Added | The path exists in the second document but not the first |
| Removed | The path exists in the first document but not the second |
| Changed | The path exists in both, but the value (or its type) differs |
A changed entry covers more than just "the number is different" — if a key holds an object in one document and a plain string in the other, that also shows as changed, with both full values shown so you can see exactly what shifted.
How arrays are compared
Arrays are compared by position, not by trying to detect that an item moved. If ["a", "b", "c"] becomes ["a", "c", "b"], the tool reports index 1 changed from "b" to "c" and index 2 changed from "c" to "b" — technically correct, but not the most intuitive way to describe "two items swapped places." This is a deliberate simplicity trade-off: detecting genuine array reordering (rather than value changes) requires a much more complex algorithm, and for the overwhelmingly common case — checking whether a specific field's value changed, or whether items were added or removed from the end of a list — positional comparison gives the right, easily verified answer.
When one array is longer than the other, the extra positions at the end show as clean additions or removals rather than changes, which is the case positional comparison handles most naturally.
Where this is genuinely useful
- API response comparison. Confirm exactly which fields an endpoint returns differently between two calls, two environments, or two versions of a service.
- Config file review. Check that an edit to a JSON config only touched the keys you meant to change.
- Data migration verification. Compare a record before and after a transformation script ran, to confirm only the intended fields changed.
- Debugging serialization. When two systems produce JSON that "looks different," this tool tells you immediately whether the underlying data actually differs or the difference is purely cosmetic (formatting, key order).
Everything above runs the moment both documents parse — neither is uploaded, logged, or stored, so comparing a real API response or config file is safe from this page's side.
FAQ
Does key order matter?
No. {"a": 1, "b": 2} and {"b": 2, "a": 1} are reported as identical — JSON objects have no defined key order, so this tool compares the actual keys and values, not the order they happen to appear in the text.
Does formatting or indentation count as a difference?
No. Both documents are parsed before comparison, so extra whitespace, different indentation, or minified versus pretty-printed JSON never shows up as a difference — only the underlying data is compared.
How do I read a path like "user.roles[2]"?
Dots step into object keys and brackets step into array indexes, left to right from the document root. "user.roles[2]" means the third item (index 2, since indexing starts at 0) of the "roles" array, inside the "user" object.
What does "(root)" mean in the path column?
It means the difference is at the very top level of the document — for example, one document is a JSON array and the other is a JSON object, so there is no meaningful key path to point to.
How are arrays compared?
By position (index), not by trying to detect that an item moved. If two array items swap places, that shows as two "changed" entries at those two positions rather than a single "moved" entry — a deliberate simplicity trade-off that still correctly flags every value that actually differs.
Are 1 and 1.0 treated as the same number?
Yes. Numbers are compared by their parsed value, not their original text representation, so 1, 1.0, and 1e0 are all treated as identical if they appear in the two documents.
What happens if one of my documents has invalid JSON?
The tool tells you which document (first or second) failed to parse, and the line and column where the problem starts, the same way the JSON Formatter tool does. Fix the syntax error and the comparison runs automatically.
Can it compare deeply nested documents?
Yes — the comparison recurses through every level of nested objects and arrays with no fixed depth limit, and every difference is reported with its complete path from the root.
Is my JSON uploaded anywhere?
No. Both documents are parsed and compared entirely in your browser. Nothing is uploaded, logged, or stored, so comparing a real API response, config file, or private data structure is safe from this page's side.
Why does changing an object to a string at the same key show as "changed" rather than "removed" and "added"?
Because the key itself still exists in both documents — only the value at that key changed (from one type to a completely different one). The tool shows this as a single "changed" entry with both the old and new value, rather than treating it as the key disappearing and a new one appearing.