API Diff Checker: Field-Level, Not Line-Level
Comparing two API responses with a plain text diff falls apart the moment key order changes or whitespace differs — neither of which affects the actual data. This tool parses both inputs as real JSON and recursively walks the structure, reporting exactly which fields were added, removed, or changed by their full key path, regardless of formatting.
Arrays are compared positionally by index — an element that moved position is reported as changed at that index, not tracked across positions.
Why Structural Diffing Beats Text Diffing for JSON
{'a':1,'b':2} and {'b':2,'a':1} are the same data with different key order — a text diff would flag this as a change; a structural diff correctly reports no difference, since it compares by key, not by line position.
Reading Key Paths
Each reported difference includes its full path from the root — user.address.city or items[2].price — so you know exactly where in a deeply nested structure the change occurred, without having to manually trace through the JSON yourself.
Practical Examples
Checking an API Version Upgrade
Comparing a v1 response against a v2 response for the same resource.
- 1.Paste the v1 example in 'Before'
- 2.Paste the v2 example in 'After'
- 3.Review exactly which fields were renamed, added, or removed
What Gets Reported
- Added keys (present only in 'After')
- Removed keys (present only in 'Before')
- Changed leaf values, with full before/after
- Full dotted/bracket key path for every difference
Good Use Cases
- Reviewing what changed between two API versions
- Verifying a webhook payload's shape is stable across events
- Checking a data migration produced the expected transformation
- Comparing two example objects from documentation
Frequently Asked Questions
How is this different from a plain text diff?
A text diff compares lines, which breaks down badly for JSON — reordered keys or reformatted whitespace show up as spurious changes even when the data is identical. This tool parses both inputs as JSON and recursively compares the actual data structure, so it reports genuine field-level differences (added/removed/changed keys) regardless of key order or formatting.
How are array differences reported?
Arrays are compared index-by-index — element 0 in 'before' is compared against element 0 in 'after', and so on, with extra elements on either side reported as added or removed. This is a positional comparison, not a smart reordering-aware diff, so array elements that just moved position will show as changed rather than matched.
What does a 'changed' entry mean for nested objects?
If a leaf value changes type or value, it's reported as a single 'changed' entry at that exact path. If a nested object gains or loses a key, that specific key is reported as added/removed at its own path, rather than the whole parent object being reported as changed.
What's this useful for besides comparing two API calls?
Comparing two versions of an OpenAPI spec's example objects, checking whether a webhook payload's shape changed between test runs, or verifying a data migration produced the expected output.
Is my data sent anywhere?
No, comparison happens entirely in your browser.