JSON Diff / Compare

Comparing two JSON files as plain text produces noise. Key order, indentation, trailing whitespace and number formatting all show up as changes even when the data is identical. This tool parses both sides into objects first and compares the parsed structures, so the result reflects what a program consuming the JSON would actually see.

Under the hood it uses the diffJson function from the jsdiff library. Each side is normalised (object keys sorted alphabetically, then pretty-printed with two-space indentation) and the two normalised texts are compared line by line. Lines present only in the right-hand document are shown in green; lines present only in the left-hand document are shown in red with a strikethrough. Everything runs in your browser, so internal API responses and audit records never leave your machine.

What counts as a difference

How to read the result

There is one output pane rather than a side-by-side view. A changed value appears as a red line (the old value) followed by a green line (the new one). Because the comparison works on pretty-printed lines, inserting one element in the middle of an array produces a single green line and the elements after it stay unmarked. A change deep inside a nested object marks only the affected line, with the surrounding structure kept for context.

Whitespace inside string values does count: "New Delhi" and "New Delhi" (two spaces) are different strings, and so are "Active" and "active". For a case-insensitive or whitespace-insensitive comparison, normalise the values before pasting.

Diff, JSON Patch and JSON Merge Patch

This page shows a human-readable diff. When a machine needs to apply the change, two standard formats exist. JSON Patch (RFC 6902) is an array of operations (add, remove, replace, move, copy, test) whose paths use JSON Pointer syntax (RFC 6901), such as /users/0/email. JSON Merge Patch (RFC 7396) is simpler: you send a partial document, and a key set to null means delete. Kubernetes accepts both through kubectl patch --type json and --type merge, and many REST APIs implement HTTP PATCH with one of them.

// JSON Patch (RFC 6902)
[{ "op": "replace", "path": "/status", "value": "active" },
 { "op": "remove",  "path": "/legacyId" }]

// JSON Merge Patch (RFC 7396) with the same effect
{ "status": "active", "legacyId": null }

Command-line equivalents

The same idea (normalise, then diff) works in a terminal. Sorting keys with jq -S is the step most people forget:

diff <(jq -S . a.json) <(jq -S . b.json)        # bash or zsh: sort keys, then diff
jq -S . a.json > a.sorted.json                  # or write the sorted copy first
python3 -m json.tool --sort-keys a.json a.sorted.json
git diff --no-index a.sorted.json b.sorted.json # coloured diff outside a repository
jq 'del(.timestamp, .requestId)' a.json        # strip volatile fields before comparing
jq '.items |= sort_by(.id)' a.json             # make array order deterministic

Getting a clean comparison

• Remove volatile fields first. Timestamps, request IDs, ETags and pagination cursors change on every call and hide the differences you care about.
• Sort arrays by a stable key. If an API does not guarantee order, sort by id on both sides so a reordering is not reported as a rewrite.
• Convert other formats first. YAML manifests and CSV exports can be turned into JSON with the YAML converter and the CSV converter, then compared here.
• Watch the number types. A field that was "42" in one release and 42 in the next is a breaking change for strictly typed clients even though the value looks the same.

1. Paste the original JSON into the left box and the modified JSON into the right box.
2. The comparison runs automatically as you type; there is no compare button.
3. Green lines exist only in the right-hand document; red, struck-through lines exist only in the left-hand one. Unchanged lines are shown for context.
4. If the whole document is highlighted, one side is probably not valid JSON. Validate it with the JSON formatter and paste it back.
5. Object key order and indentation are ignored automatically, so there is no need to format either side first.

• Confirming that a refactored endpoint returns the same response body as the version it replaces.
• Comparing the configuration JSON of two environments (staging and production) to find drift.
• Reviewing a Terraform plan or CloudFormation template exported as JSON before applying it.
• Checking what changed in package-lock.json or tsconfig.json between two branches.
• Comparing analytics or webhook payloads emitted by two versions of a service.
• Verifying that a database export matches a known-good snapshot after a migration.