Compare API responses without hiding a regression
Use downloadable API snapshots to separate request metadata, reordered records and a real price edit, with exact expected results.
By Sujit Maharjan. Published .
Build a comparison you can explain: record the options, isolate the edit and keep the original snapshots.
Decide what should remain stable
Two responses from the same endpoint rarely have identical text. Request IDs change, records may arrive in a different order, and formatting varies between clients. Ignoring all of that can make a useful comparison. It can also hide the bug.
Write the expectation first. In this exercise, product IDs identify records, record order is not part of the endpoint’s contract, requestId is diagnostic metadata, and price must remain stable. Those are assumptions for this invented endpoint, not rules to apply to every API.
Save products-before.json and products-after.json. They contain invented records, including a reordered list and one price change. Open JSON Diff Checker and import each file on its corresponding side.
Start with the unfiltered comparison
The first response contains:
{"requestId":"demo-1","products":[{"id":"sku-a","price":19.5},{"id":"sku-b","price":8}]}The second contains:
{"requestId":"demo-2","products":[{"id":"sku-b","price":8},{"id":"sku-a","price":21}]}With default positional comparison, expect five changed entries: requestId plus the id and price at each of the two array positions. There are no added or removed entries. These counts describe reported paths, not changed source lines or a count of business events.
Keep this baseline. Beginning with a large ignore list makes it harder to notice that a supposedly irrelevant field actually changed. If the baseline fails to match the expected five entries, reset the tool and check whether an old ignore list or ID mode is still active.
Ignore one field for a stated reason
In Advanced options, enter /requestId in Ignore JSON Pointers. Keep positional array comparison. The expected changed-entry count is now four: both positions still hold a different record.
The pointer names the exact root-level field. /meta/requestId would name a different location. A key containing a slash uses ~1, and a key containing a tilde uses ~0. For example, /a~1b/~0tag addresses the key ~tag inside a/b. The tool accepts comma-separated exact pointers; it does not support wildcard matching or keys containing a literal comma in this control.
Before ignoring a field, ask whether its change could affect the behavior under investigation. Timestamps can control expiry; status fields can control access; version fields can select a schema. Their names alone do not make them irrelevant. Keep the chosen pointers alongside the result in your bug report.
Match records only when order is irrelevant
Choose By unique ID field and enter id. Keep /requestId ignored. The expected result is one changed entry: products[0].price, from 19.5 to 21.
The displayed index is zero because the tool sorts by serialized IDs before comparison. In this normalized order, sku-a comes before sku-b. In the original second response, sku-a was at index one. Use the record ID to explain the edit; do not treat the normalized path as an index into the untouched response.
| Options | Changed entries | Interpretation |
|---|---|---|
| Defaults | 5 | Request metadata and positional record differences |
Ignore /requestId | 4 | Positional record differences remain |
Ignore /requestId, match by id | 1 | sku-a price changes from 19.5 to 21 |
ID mode applies to every array in the supplied document. Each item must be an object with a unique primitive ID. A nested array of strings, missing ID or duplicate ID can make this mode unsuitable. Compare a relevant record array separately or keep positional comparison when your document does not meet those conditions.
Explain what the result establishes
A clean normalized comparison establishes equality only under the options you selected and the parser’s representation. It does not establish that the original files are identical, that their signatures match, or that either response satisfies an API schema.
Keep IDs as strings in this workflow when exact digits matter. JavaScript parsing can collapse different large numeric tokens to the same value and retain only the last duplicate object name. Use the JSON parsing investigation if a supposedly identical document may have lost information before comparison.
For a reproducible report, attach the two synthetic snapshots, state the ignored pointers and array mode, identify the changed record and describe the expected contract. If order is meaningful—for example, a ranked search result—keep positional mode and treat reordering as evidence. Do not remove a difference merely to obtain Identical.
Sources and limits
RFC 6901 specifies JSON Pointer syntax. RFC 8259 describes JSON arrays and object interoperability. ID sorting, display paths and the expected counts here describe this tool’s implementation.
Each normalized document is limited to 2,000 formatted lines and nesting deeper than 100 levels is rejected. Local imports accept files up to 200 KB; input validation also limits characters. Split large responses into relevant sections without discarding context needed to interpret the change. The files and expected outcomes are checked by automated tests. AI assisted drafting; no customer incident or production endpoint is claimed.