API response diff

Compare two API responses without the noise

Two calls to the same endpoint almost never return byte-identical JSON: a request id, a generatedAt stamp or a freshly minted UUID changes on every hit, and a plain text diff buries the one field you actually care about. This tool compares the two responses structurally and lets you drop the volatile parts first, so what is left is the real behavioural change.

It is built for the everyday API jobs: checking a staging deploy against production, reviewing a version bump (/v1 vs /v2), confirming a cache or pagination fix changed nothing else, and turning "these look different" into a precise list of paths.

Everything runs locally in your browser through WebAssembly — the two responses are never uploaded anywhere.

Worked example

First response (baseline)

{"requestId":"req-8f21","generatedAt":"2026-08-15T09:14:02Z","data":{"total":2,"status":"ok"}}

Second response (candidate)

{"requestId":"req-c07d","generatedAt":"2026-08-16T11:02:47Z","data":{"total":3,"status":"ok"}}

With Ignore fields set to requestId, generatedAt, the result is:

{
  "equal": false,
  "counts": {
    "added": 0,
    "removed": 0,
    "changed": 1,
    "type_changed": 0,
    "ignored": 2
  },
  "truncated": false,
  "notes": [],
  "ignored_paths": [
    "$.requestId",
    "$.generatedAt"
  ],
  "changes": [
    {
      "path": "$.data.total",
      "kind": "changed",
      "old": 2,
      "new": 3
    }
  ]
}

One real change ($.data.total went from 2 to 3), two fields deliberately skipped — and equal tells you at a glance whether anything meaningful moved.

Switch Output to Readable summary for a one-line-per-change view (~ $.data.total: 2 -> 3), or to RFC 6902 JSON Patch to get [{"op":"replace","path":"/data/total","value":3}] you can feed to a patch library.

Ways to say "ignore this"

• By name — updatedAt skips that key wherever it appears, at any depth.
• By pattern — *_at skips created_at, updated_at, expires_at; $.data.items[*].token skips one token field per element; ** matches any number of path segments.
• By exact path — data.token (or $.data.token) only matches at the root position.
• By shape — the Ignore timestamp-shaped values and Ignore UUID-shaped values checkboxes drop a change when both sides look like a timestamp or a UUID, which is handy when the volatile field names are not known up front.

Skipped locations are counted and listed under ignored_paths, so a filter can never hide a change silently.

Arrays: index, key, or set

Collections are where JSON diffs usually go wrong. Three matching modes cover the common cases:

• By position (index) — the default, and the only mode that can produce a JSON Patch.
• By key field — pairs objects by id (or any field you name), so a list that came back in a different order still diffs field-by-field. Paths read $.items[id=a1].price.
• As an unordered set — elements are matched as a multiset; anything left over is reported as added or removed. Use it when order genuinely carries no meaning.

If an array cannot be matched by key (elements are not objects, or the key repeats), the comparison falls back to index matching and says so in notes rather than failing.

Limits and edge cases

• Each response is capped at 4 MiB; larger payloads are rejected with a clear message.
• At most 2000 changes and 2000 ignored paths are listed; truncated becomes true while the counts stay exact.
• Arrays longer than 2000 elements fall back to index matching in key/set mode (noted in notes) because pairing cost grows quadratically.
• output=patch requires index array matching — JSON Pointer positions are not well defined once elements are paired by key or as a set.
• Deeply nested documents (beyond serde_json's ~128 level recursion limit) are rejected as invalid JSON rather than crashing.
• Both inputs must be valid JSON; errors name the side and the line/column, e.g. left response is not valid JSON: expected value at line 1 column 2.

FAQ