Paste the old and new JSON responses into JSON Diff. The result names changed values by path and separates additions, removals, and type changes. Use that list to decide which differences deserve an assertion or a contract review.
\n\nAn API test says only that the response changed. Scanning two formatted payloads can miss a number that became a string, especially when most fields stayed the same. A plain text diff also spends space on indentation and property order. Start with the values.
\n\nOpen the tool. Replace the left pane with the earlier response and the right pane with the new one. The comparison updates as you edit; there is no run button.
\n\n{\"id\":\"A-17\",\"status\":\"pending\",\"amount\":499,\n \"items\":[{\"sku\":\"P1\",\"qty\":1}]}{\"id\":\"A-17\",\"status\":\"paid\",\"amount\":\"499\",\n \"items\":[{\"sku\":\"P1\",\"qty\":1}],\"paymentId\":\"p_8\"}The result has 1 added, 0 removed, 2 changed, and 3 unchanged leaf values. It lists status as changed, amount as a type change, and paymentId as added. The id and the two fields inside items[0] did not change. That is more useful than a red/green block around the whole response: amount now needs a contract decision, while paymentId may be an intentional addition.
The tool parses both panes as JSON and walks matching object keys and array positions. items[0].qty is the quantity in the first array element. If an item moves from index 0 to index 1, the tool compares those positions and may report several changes even when the item itself is unchanged. It does not match records by sku or another identity field.
That matters for API assertions. If item order is part of the contract, positional differences are evidence. If order is irrelevant, compare items by a stable key in the test instead. JSON Formatter helps when either side is invalid; this diff tool reports which pane failed to parse, but it cannot infer a missing comma's intended value.
\n\nThe tool reports structure and values, not whether a release is compatible. RFC 8259 defines an object as an unordered collection and an array as ordered; the tool's positional array comparison follows that distinction. A new optional property may be harmless for one consumer and break another that rejects unknown fields. Check the actual consumer contract before labeling a change safe.
\n\nFor a repeated check in CI, write an assertion or validate against the agreed schema. A browser comparison is useful during investigation, but it is not a stored regression test.
\n\nDoes key order matter here? JSON object member order carries no meaning in RFC 8259, and the tool compares keys rather than text positions. Array order does affect its result.
\n\nCan I paste a broken response? You can, but the tool stops at the JSON parse error and identifies the invalid pane. Repair or isolate that input before interpreting differences.
\n\nCompare one response from before and after a real change. Save the changed paths, the two values, and the consumer decision. Turn each consequential difference into a test that checks the intended contract.
\n\n