How to review json data file changes in pull requests
- Step 1Get the old version of the JSON file — From the PR's base: open the file at the base commit (GitHub's 'View file' on the parent, or
git show main:data/fixtures.jsonlocally). Copy the full JSON. - Step 2Get the new version from the PR — Open the changed file on the PR head (the 'View file' button on the diff) and copy the full new JSON. You want the two complete versions, not the patch hunk.
- Step 3Paste the old version on the left — Paste the base-commit JSON into
JSON A (base). It must be a single valid JSON value — an object or an array at the top level both work. - Step 4Paste the new version on the right — Paste the PR-head JSON into
JSON B (modified). Both panels are required before the tool runs. - Step 5Click Compare and read the semantic change — The list shows added keys, removed keys, and changed values at their paths. This is what to review — verify each
changedvalue is intentional, eachaddedentry is wanted, and eachremovedentry is safe to drop. - Step 6Summarise the change in your PR comment — Use
Copy JSONto grab the diff, then describe it semantically in the review: 'Adds 3 user fixtures, changes product 42 price 10.00 → 12.00, removes the deprecatedbetaFlagkey.' That's far more useful to the author than quoting raw patch lines.
git line diff vs this semantic diff for a JSON PR
Why a semantic diff beats the patch view for data-file review. Both run after you paste the two file versions.
| PR situation | git line diff shows | This tool shows |
|---|---|---|
| Reformatted / re-indented file | Hundreds of changed lines | No differences — pure formatting, key order ignored |
| Keys sorted alphabetically | Most lines moved (red+green) | No differences — object key order is ignored |
| One value changed | Often clear, but path is implicit | changed users[12].plan - "free" + "pro" with the exact path |
| One fixture inserted near the top of an array | Every following line marked changed | Array compared by index — also shows shifted elements as changed (see edge cases) |
| Type change in a value | Looks like a quote-character edit | changed id - "42" + 42 — type shift is explicit |
What the diff reports for common PR JSON edits
Verified against the diff engine. Use these to predict and explain the output in review.
| Edit in the PR | A → B | Diff output |
|---|---|---|
| New translation key | {"hello":"Hi"} → {"hello":"Hi","bye":"Bye"} | added bye with + "Bye" |
| Translation value edited | {"title":"Cart"} → {"title":"Basket"} | changed title - "Cart" + "Basket" |
| Removed deprecated key | {"a":1,"old":2} → {"a":1} | removed old with - 2 |
| Fixture appended to array | [{...}] → [{...},{...}] | added [1] with the whole new object |
| Key only reordered | {"a":1,"b":2} → {"b":2,"a":1} | No differences |
Cookbook
Real (anonymised) JSON PR reviews. Left is the base-commit version, right is the PR head. The diff is what you'd paste into the review thread.
A translation-file PR that's mostly reformatting
ExampleThe PR claims 'add one string' but the git diff is 400 lines because a pre-commit hook sorted keys. The semantic diff proves only one key was actually added.
JSON A (main): JSON B (PR head, keys sorted):
{ {
"welcome": "Hi", "bye": "Bye",
"cart": "Cart" "cart": "Cart",
} "welcome": "Hi"
}
Diff:
+1 added
added bye
+ "Bye"
→ Despite a 400-line git diff, exactly one real change.A seed-data value change you can quote precisely
ExampleThe PR bumped a product price. The diff gives you the exact path and both values to put in the review comment.
JSON A: JSON B:
{ {
"products": [ "products": [
{ "id": 42, { "id": 42,
"price": 10.00 } "price": 12.00 }
] ]
} }
Diff:
~1 changed
changed products[0].price
- 10
+ 12
→ Comment: 'product 42 price 10 → 12 — intended?'Spotting a type change snuck into a fixture
ExampleA find-and-replace turned a numeric id into a quoted string in one fixture. The diff catches the type flip that a reviewer scanning quotes might miss.
JSON A: JSON B:
{ "userId": 7 } { "userId": "7" }
Diff:
~1 changed
changed userId
- 7
+ "7"
→ Type changed number → string. Likely a bad sed.Inserted fixture shifts later array elements
ExampleBecause arrays compare by index, inserting a fixture at position 0 reports the inserted item plus every shifted element as changed. Knowing this, you read it as 'one insert' rather than panicking at the count.
JSON A: JSON B:
[ [
{ "name": "a" }, { "name": "z" },
{ "name": "b" } { "name": "a" },
] { "name": "b" }
]
Diff:
~2 changed +1 added
changed [0].name - "a" + "z"
changed [1].name - "b" + "a"
added [2] + { "name": "b" }
→ Really a single prepend; index shift inflates the count.Confirming a 'no functional change' refactor of a JSON file
ExampleA PR re-indents and reorders keys but swears it changes no data. An identical result is the proof for the reviewer to approve fast.
JSON A (2-space, unsorted): JSON B (4-space, sorted):
{"b":2,"a":1} {
"a": 1,
"b": 2
}
Diff:
No differences
→ The two JSON values are identical. Safe formatting-only PR.Errors and edge cases
Real errors and silent failures sourced from each platform's own documentation. Match the wording to the row, fix what the row says to fix.
An inserted array element inflates the change count
Positional by designArrays are compared by index. Insert a fixture at the top of an array and every later element lines up against a different position, so you get a run of changed entries plus one added at the end. The actual edit was one insert — read the pattern (a contiguous shift) rather than the raw count. For value-keyed arrays, sort both by a stable key before pasting.
Type change reads as `changed`, not a typed flag
By designA fixture id that went from 7 to "7" shows as a changed entry whose from/to reveal a number became a string. There's no special type badge — but for review purposes the value pair is exactly the evidence you need to question a careless find-and-replace.
Pasted the patch hunk instead of the full file
Parse errorThe inputs must each be a complete valid JSON value. Pasting a git patch (with @@ headers and +/- prefixes) throws a JSON.parse error. Copy the full file content from each version's 'View file' page, not the diff hunk.
Trailing comma or comment in the fixture
Parse errorStrict JSON.parse rejects trailing commas, comments, and unquoted keys. If your fixtures use JSON5/JSONC conveniences, repair them to strict JSON first with /tool/json-format-fixer, then diff the cleaned versions.
Only one version pasted
InvalidBoth JSON A and JSON B are required. An empty or whitespace-only panel returns Please provide both JSON A and JSON B. Grab both the base-commit and PR-head versions before running.
Large fixture over 2 MB per side
Upgrade requiredOn free, each pasted version is capped at 2 MB; a large seed file returns Free plan supports JSON inputs up to 2 MB. Upgrade to Pro for unlimited input size. Diff only the changed sub-tree (extract it with /tool/json-path-extractor) or upgrade to Pro.
Key only reordered or whitespace-only change
SupportedA PR that just sorts keys or reformats produces The two JSON values are identical. because objects are compared by key, not position, and whitespace is irrelevant after parsing. That's your fast-approve signal for a formatting-only change.
`null` value removed vs key deleted
RemovedA fixture key set to null in the base and absent in the PR head reports removed of a null value, because null is a present value. If your fixtures treat null and 'omitted' the same way, read these as equivalent during review.
Frequently asked questions
How do I make git diffs of JSON files more readable without an external tool?
Configure git to canonicalise JSON before diffing. Add *.json diff=json to .gitattributes and set a textconv filter: git config diff.json.textconv 'jq --sort-keys .'. Now git's own diff sorts keys and pretty-prints, so reordering and formatting stop showing as changes. Use this paste tool when you want the change as a path-indexed semantic list to quote in a review.
Why did inserting one array item produce so many changes?
Arrays are compared by index, so inserting near the top shifts every later element to a new position, and each shifted element reads as changed. The edit is really one insert — recognise the contiguous-shift pattern. For arrays where identity matters, sort both versions by a stable key (an id) before pasting so the diff matches items, not positions.
How should I review large translation JSON file changes in PRs?
Focus on the three diff types: added keys (verify they have values in every required locale and are actually used), changed values (verify the wording change is intentional and correct), and removed keys (verify they're no longer referenced anywhere in the codebase). The semantic list makes each category easy to scan instead of hunting through a reordered patch.
Does the tool ignore reformatting and key sorting?
Yes. Objects are compared by key and values are compared after parsing, so re-indentation, whitespace, and alphabetised keys all diff clean. A PR that only reformats a JSON file shows The two JSON values are identical. — your evidence to approve quickly.
Can I paste the GitHub diff hunk directly?
No — the hunk (with @@ markers and +/- line prefixes) isn't valid JSON and will fail to parse. Open each version's full file ('View file' on the base commit and on the PR head), copy the complete JSON, and paste the two versions into the base and modified panels.
How do I quote a change in my review comment?
Copy the diff with Copy JSON and translate it to plain language: each changed entry gives you a path and both values, so you can write 'product 42 price 10 → 12' or 'removed deprecated betaFlag'. That's far more actionable for the author than pasting raw patch lines.
What about a type change hidden in a fixture?
The diff fires on serialized inequality, so a value that went from 7 to "7" (number → string) appears as a changed entry exposing both values. This is exactly the kind of accidental change a careless sed/find-replace introduces and a line-based review easily misses.
Is there a size limit on the fixture I can review?
Free inputs are capped at 2 MB per side. For a large seed file, extract just the changed section from both versions with /tool/json-path-extractor and diff those, or upgrade to Pro to remove the cap. Reviewing a focused sub-tree is usually clearer anyway.
Can I review multiple changed JSON files at once?
No — this is a two-input, one-pair tool. Review each changed file's old/new versions as a separate diff. If the PR splits one logical dataset across files, merge each side first with /tool/json-object-merger, then diff the merged objects.
Is the JSON file data transmitted to JAD Apps?
No. Both versions are parsed and diffed in your browser. Test fixtures, seed data, and translation files — including proprietary or internal content — are never sent to a server. Clicking Compare makes no network request.
How do I sort an array by id before diffing so items match?
The diff tool itself doesn't sort. Pre-process each version so the array is in a stable order keyed on an identifier — for example flatten with /tool/json-flattener or transpose/reshape with /tool/json-transposer into a keyed structure, then diff. Once both sides are in the same order, index-based comparison matches the right items.
Why does the stats line matter for review triage?
The +N -N ~N summary tells you the true size of a JSON change before you read it. A PR described as 'small fixture tweak' that shows ~38 changed deserves more scrutiny — and one showing identical is a safe formatting-only change you can approve fast.
Privacy first
Conversion runs locally in your browser. No file is uploaded — only metadata counters are saved for signed-in dashboard stats.