Validate JSON Changes Before and After Deployment

The release bumped an API version string and added one feature flag. The diff confirms nothing else moved — exactly the evidence a runbook wants.

JSON A (pre-deploy):           JSON B (post-deploy):
{                              {
  "apiVersion": "2.3.0",         "apiVersion": "2.4.0",
  "flags": { "newNav": false }   "flags": { "newNav": true }
}                              }

Diff:
~2 changed
changed  apiVersion  - "2.3.0" + "2.4.0"
changed  flags.newNav  - false  + true
→ Both changes are intended. Pass.

The release accidentally dropped pricing.currency from the response. A removed entry stops the rollout before a client crashes on the missing field.

JSON A (pre):                  JSON B (post):
{                              {
  "pricing": {                   "pricing": {
    "amount": 1999,                "amount": 1999
    "currency": "USD"            }
  }                            }
}

Diff:
-1 removed
removed  pricing.currency
  - "USD"
→ Unintended removal. Stop and roll back.

A DB migration meant to keep quantity as a number accidentally serialized it as a string. The diff exposes the type flip as a changed entry.

JSON A (record before):        JSON B (record after):
{                              {
  "sku": "AB-12",                "sku": "AB-12",
  "quantity": 10                 "quantity": "10"
}                              }

Diff:
~1 changed
changed  quantity  - 10  + "10"
→ Type flipped to string. Breaking for typed consumers.

If you diff a record with an updatedAt, it will always change. Either accept the single expected entry or strip it from both snapshots first so the diff shows only the deploy's real effect.

Strip updatedAt from both with the null/key tools first, then:

JSON A:                        JSON B:
{ "status": "active" }         { "status": "active" }

Diff:
No differences
→ The two JSON values are identical. (updatedAt excluded.)

Part of validation is proving the deploy did NOT touch endpoints it shouldn't. An identical result is positive evidence.

JSON A (pre, /v1/regions):     JSON B (post, /v1/regions):
{ "regions": ["us","eu"] }     { "regions": ["us","eu"] }

Diff:
No differences
→ The two JSON values are identical.
→ Attach to ticket: /v1/regions unaffected by release.

An updatedAt, generatedAt, or requestId differs on every capture and shows as a changed entry that has nothing to do with your release. Either strip those fields from both snapshots before pasting (use /tool/json-key-filter or /tool/json-null-stripper as appropriate) or mentally exclude them when reading the diff.

A migration that turns 10 into "10" is caught — as a changed entry whose from/to reveal a number became a string. There is no special type-mismatch badge; the value pair is the evidence, and for deployment validation a type flip is almost always a stop-the-rollout finding.

Arrays compare by index, so a post-deploy response that returns the same items in a different order produces changed [0], changed [1], and so on. If ordering isn't part of the contract, sort both snapshots' arrays before pasting so true item changes aren't buried.

Both inputs go through strict JSON.parse. A capture that includes log prefixes, headers, or a data: wrapper throws a parser error. Paste only the JSON body; if your capture is near-JSON (trailing commas, comments), repair it first with /tool/json-format-fixer.

Both JSON A and JSON B are required; an empty or whitespace-only side returns Please provide both JSON A and JSON B. Capture both the pre- and post-deploy snapshots before running the comparison.

Each pasted snapshot is capped at 2 MB on free; over that returns Free plan supports JSON inputs up to 2 MB. Upgrade to Pro for unlimited input size. Snapshot one representative item or extract the relevant sub-tree with /tool/json-path-extractor to stay under the cap, or upgrade to Pro.

JSON.parse reads 1 and 1.0 as the same number, so a numeric-formatting change between captures is invisible here. If a serializer-precision change is what you're validating, this tool can't detect it — the distinction is lost at parse time.

When the before and after match (after key-order normalisation), the panel shows The two JSON values are identical. For an endpoint or record that the release should not have touched, that is exactly the green light you want to record.