Json Diff

Paste the original and the changed JSON to see exactly what differs. The tool parses both documents, walks the structure and lists every added, removed and changed value with its JSON path — ignoring key order and whitespace, so only real data changes show. Nothing leaves your browser.

Why a structural JSON diff

A plain text diff compares characters and lines, so two JSON documents with the same data can look completely different if keys are in another order or the formatting changed. A structural diff parses both documents first and compares the data: objects key by key, arrays item by item, and values by type and content. The result is a short list of real changes with a path to each one, which is what you need when checking an API response, a configuration change or a data migration.

How to read the results

Paths use JSONPath-style notation: $ is the root, .name is a key and [2] is an array index. Keys with spaces or special characters are shown in brackets and quotes, such as $["unit price"].

Options explained

• Treat 1 and 1.0 as equal — JSON numbers have no separate integer type; this avoids reporting 349 vs 349.0 as a change. (Once parsed they are the same number anyway; the option matters when comparing numbers written differently, such as 1e2 and 100.)
• Ignore array order — compares arrays as unordered collections, useful for tags or IDs where order does not matter. Items are matched by their full content; changed items show as one removed and one added.
• Format both — pretty-prints both documents with two-space indentation, which makes them easier to read.

Worked example

Comparing the two product records above gives six differences: $.name changed from “Standing Desk” to “Standing Desk Pro”; $.price changed from 349 to 379; $.tags[2] added (“adjustable”); $.stock.warehouse changed from 12 to 9; $.stock.store removed; and $.colors added. The id and discontinued flag are unchanged, and the different key order is ignored.

Common uses

• API testing — compare a response with an expected fixture or a previous version.
• Configuration reviews — see exactly which settings changed between environments.
• Data migrations — check a record before and after transformation.
• Debugging — find the one field that differs between a working and a failing request.
• Contract changes — spot fields added or removed in a new API version.

Valid JSON checklist

If a document does not parse, the error message shows the problem and its position. JSON5 and JavaScript object literals are more permissive and must be converted to strict JSON first.

Large documents and performance

The comparison walks each value once, so it handles documents of several megabytes comfortably in a modern browser. Extremely large files may be slow to paste into a text box; for automated comparisons in code, use a JSON diff library or a test framework’s deep-equality assertion, and use this tool for quick manual checks.

JSON Patch

The differences listed here correspond closely to the operations in JSON Patch (RFC 6902): add, remove and replace. If you need to send changes to an API that accepts JSON Patch, the report is a useful starting point, though the path syntax in JSON Patch uses slashes (/stock/warehouse) rather than dots.

Comparing API responses in practice

1. Capture a known-good response and save it as a reference fixture.
2. After a code or configuration change, capture the new response for the same request.
3. Paste both here and review the report.
4. Decide whether each difference is expected. Added fields are usually safe for clients; removed fields and type changes are often breaking.
5. Record intended changes in your API change log and update tests and documentation.

Remember that some values change on every request — timestamps, request IDs, pagination cursors. Remove or replace them with placeholders before comparing, so the report shows only meaningful differences.

Type changes to watch for

A value that changes type — for example a number that becomes a string (42 to "42"), or a single object that becomes an array — is shown as “changed”. These changes are easy to miss in a text diff but frequently break client code, because strongly typed languages and validators reject the new type. Null handling is another source of bugs: a field that switches between null and missing looks similar to a human but is treated differently by many parsers.

Privacy

Both documents are parsed and compared in your browser with JavaScript. Nothing is uploaded, logged or stored, so it is safe to compare internal API responses and configuration files — though, as always, avoid pasting secrets such as API keys into any web page.