API response comparison
Compare JSON responses from v1 and v2 endpoints to confirm added fields, removed fields, and value changes during integration or regression testing.
A: JSON A
B: JSON B
JSON Diff and Compare Tool
Compare two JSON documents side by side, inspect added, removed, and changed fields, and export summaries, Markdown reports, or JSON Patch. Everything runs locally in your browser.
Press Ctrl/Cmd+D to bookmark this tool
Best-fit scenarios
Configuration drift review
Compare development, staging, and production JSON config files while using ignore-order rules to reduce irrelevant noise.
Data migration validation
Check old and new JSON structures after migration work so renamed fields, default values, and split objects are easy to verify.
Log and snapshot comparison
Compare two requests, logs, or state snapshots to understand exactly what changed before and after an issue appeared.
Two JSON file diff
Import or paste two JSON files and inspect structural and field-level differences for configs, exports, fixtures, or API samples.
How to compare two JSON files and understand the changes quickly
1Import two JSON payloads that actually belong in the same comparison2Configure ignore rules based on the business meaning of the data3Read the diff, counts, and summary together4Export the output that fits your downstream use case
The compare page works best when you treat it as a structured change review tool, not just a place to paste two blobs of text. Bring in clean inputs, choose the right ignore rules for your data, and export the output in the format that matches your workflow.
Understand version drift before acting on it
The compare tool helps answer what changed, not just whether the text looks different
In most workflows, you care about whether fields were added, removed, or changed in meaning, not whether two files differ by whitespace or order. That is why a structural JSON compare is more useful than plain text diff.
JSON A (older version)
1
{
2
"id": 1,
3
"name": "Maeve",
4
"status": "active",
5
"roles": ["admin", "editor"]
6
}
JSON B (newer version)
1
{
2
"id": 1,
3
"name": "Maeve Winters",
4
"status": "active",
5
"roles": ["admin", "editor"],
6
7
}
If you only need the high-level answer first, read the summary. If you need exact field-level context, stay in the diff view.
3 compare examples that reflect real work
These examples mirror the most common JSON diff workflows in development, QA, and operations: API upgrades, environment config review, and data migration verification.
API Versioning
Compare API response v1 and v2 to confirm added fields
This is ideal when frontend and backend teams need to verify exactly what changed between response versions.
Response v1
1
{
2
"user": {
3
"id": 42,
4
"name": "Maeve"
5
},
6
"status": "active"
7
}
Response v2
1
{
2
"user": {
3
"id": 42,
4
"name": "Maeve"
5
},
6
"status": "active",
7
"profile": {
8
9
}
10
}
This kind of diff is especially useful when you need to verify added fields before updating tests or frontend models.
Environment Config
Remove ordering noise so the real config differences stand out
When object keys or array members are semantically unordered, selective ignore rules can reduce a lot of useless diff noise.
Staging
1
{
2
"features": ["coupon", "betaCheckout"],
3
"retry": 2,
4
"timeout": 5000
5
}
Production
1
{
2
"features": ["betaCheckout", "coupon"],
3
"retry": 3,
4
"timeout": 5000
5
}
With ignore order enabled, the important change becomes obvious: retry changed, while the feature list did not meaningfully drift.
Migration Review
Check data migration output and export a Patch for automation
This works well when old structures are being split, renamed, or normalized into a new shape.
Before migration
1
{
2
"fullName": "Maeve Winters",
3
"active": true
4
}
After migration
1
{
2
"firstName": "Maeve",
3
"lastName": "Winters",
4
"status": "active"
5
}
If the migration pipeline needs repeatable change application, exporting both the Markdown report and JSON Patch is often worthwhile.
- 01
Tutorial Step
Step 1 - Import two JSON payloads that actually belong in the same comparison
Before you look at the diff, be clear about what each side represents: old versus new, staging versus production, previous response versus current response. That mental model makes the later change review much easier.
- Put the baseline payload on the left and the target or newer version on the right so A to B has a stable meaning.
- Import from files, URLs, or clipboard when that is easier than manual paste, especially for config or exported data.
- If either side has not been validated yet, run it through the validator first so syntax errors do not distort the compare result.
- Try to compare payloads from the same business scope or time window so you do not mix unrelated changes into one review.
- Check the imported names or source labels before reviewing the diff so you do not accidentally reverse the sides.
- 02
Tutorial Step
Step 2 - Configure ignore rules based on the business meaning of the data
Ignore whitespace, case, and order are useful only when they match the meaning of your data. The fastest approach is to choose them intentionally instead of enabling every option by default.
- Enable ignore whitespace when you only care about content and structure, not formatting differences.
- Enable ignore case when keys or string values vary in case but not in meaning.
- Enable ignore order only when the order of items should not count as a change.
- When any ignore rule is enabled, the page switches to a normalized preview so the highlights match the actual comparison logic.
- If you are unsure whether order matters, review the raw diff first and turn on ignore order only after you confirm the noise pattern.
- 03
Tutorial Step
Step 3 - Read the diff, counts, and summary together
A useful comparison is more than colored highlights. The best signal usually comes from combining three things: the field-level diff, the change counts in the status area, and the high-level summary you can copy or export.
- Side-by-side view is best when you want to inspect nested objects and field-level changes carefully.
- Inline view is useful on smaller screens or when you want to scan the full set of changes quickly.
- The status area shows total changes as well as how many additions, deletions, and modifications were found.
- Copy Summary is useful when you need to explain the result quickly in a ticket, chat, or review thread.
- If the diff suddenly looks much larger than expected, confirm that the two payloads actually come from the same source scope before digging deeper.
- 04
Tutorial Step
Step 4 - Export the output that fits your downstream use case
This page does not just show differences. It can produce three useful outputs depending on what happens next: summary text for communication, Markdown reports for documentation, and JSON Patch for automation.
- Copy the summary when you need a quick explanation for chat, tickets, release notes, or QA updates.
- Export the Markdown report when you want a more formal record of the comparison and the changes discovered.
- Export JSON Patch when you need to apply or test the A to B transformation programmatically.
- For config comparisons, keep the report with version identifiers so rollback and audit are easier later.
- If one of the payloads still needs field-by-field review, move it into the table editor after the comparison step.
A more reliable compare workflow
1
Validate both payloads first so broken JSON does not pollute the diff.
2
Review the raw comparison once before enabling ignore rules so you understand what noise is present.
3
Use the diff highlights, counts, and summary together to judge the scale and type of change.
4
Use summary text for communication, Markdown reports for records, and JSON Patch for automation.
5
If one side still needs field-level inspection or editing, continue into the formatter or table editor after comparison.
The compare page is best used to answer not whether two files look different, but where the JSON structure and meaning actually changed.
JSON compare tips
If the diff looks much bigger than expected, first check whether the two payloads came from different scopes or time windows.
Do not enable ignore order when sequence itself has business meaning.
Use the summary for fast communication, the report for documentation, and JSON Patch for automation. Each output solves a different problem.
If the diff is hard to read, format both payloads first, then compare again.
Related JSON comparison and diff tools
Use these tools with comparison when you need validation, formatting, or downstream code generation.
Frequently Asked Questions
How does the JSON compare tool work?
This page compares JSON structurally rather than character by character. It detects additions, deletions, and modifications at the object, array, and nested field level, which makes it much more useful than plain text diff for API responses, config files, and data snapshots.
Is my JSON uploaded anywhere?
No. Comparison, normalized preview, summary generation, Markdown report export, and JSON Patch export all run locally in your browser.
What do ignore whitespace, ignore case, and ignore order actually do?
Ignore whitespace helps remove formatting noise, ignore case is useful when key casing or string casing is inconsistent, and ignore order is best when array order is not meaningful but the set of values still matters.
Can ignore order hide real changes?
Yes. If array order has business meaning, such as time series, ranked lists, or ordered workflows, you should not enable ignore order. It is better suited to unordered sets such as tags, permissions, or config collections.
Why does the editor become read-only when ignore options are enabled?
Because the page switches to a normalized preview rather than showing the raw source exactly as typed. Read-only mode prevents confusion and keeps the diff highlights aligned with the comparison rules you enabled.
What is JSON Patch and why would I export it?
JSON Patch is a standard set of add, remove, replace, and related operations that transform one JSON document into another. It is useful for environment sync, automated change application, and API test workflows.
Should I validate or format the JSON before comparing it?
Validation first is recommended. If one side is invalid JSON, the diff is less trustworthy. Formatting can also help readability, especially before comparing large payloads.
What kinds of workflows is this compare page best for?
It works especially well for API version comparisons, environment config drift checks, data migration review, release verification, and debugging differences between two recorded responses.
When should I use the Markdown report?
Use the Markdown report when you need to paste a readable diff summary into tickets, release notes, QA records, or code review discussions.
How should I compare very large JSON payloads?
Validate first, then compare only the relevant sections when possible. If the payload contains a lot of order or formatting noise, use the ignore options selectively so the important structural changes stand out.