comparator.json.labelA
Loading Editor...
comparator.json.labelB
Loading Editor...
You have two JSON objects. They should be the same. They're not.
Maybe it's an API response before and after a deployment. Maybe it's a config file from two different environments — staging and production — and something is behaving differently and you can't figure out why. Maybe it's a test assertion failure where the expected and actual payloads are both 200 lines deep and the error message just says "objects do not match."
Manual comparison at that scale isn't just tedious — it's unreliable. Human eyes miss things. Especially in deeply nested JSON. Especially when you're tired, under pressure, and the CI pipeline is red.
Paste both JSON objects above. Every difference — added fields, removed fields, changed values, type mismatches — is highlighted instantly, side by side, with the exact path to each change.
The instinct when comparing JSON is to reach for a text diff tool — the same tool you'd use for code review or document comparison. That instinct leads you astray, and here's why.
Text diff is format-sensitive. JSON diff is structure-sensitive.
Consider these two JSON objects:
{"name":"Alice","roles":["admin","editor"],"active":true}{
"active": true,
"name": "Alice",
"roles": [
"editor",
"admin"
]
}A text diff tool would flag every single line as different — the objects are formatted differently and the keys are in a different order. But semantically, these two objects are identical. The data is the same. A text diff gives you noise. A JSON diff gives you signal.
Now consider this pair:
{
"user": {
"id": 101,
"name": "Alice",
"role": "admin"
}
}{
"user": {
"id": 101,
"name": "Alice",
"role": "editor"
}
}One field changed. One. A text diff shows you one changed line. A JSON diff shows you the exact path — user.role changed from "admin" to "editor" — so you know immediately what changed, where it is in the structure, and what both values were. No scanning. No context-reading. No margin for missing it.
Our JSON comparator performs structural diffing — comparing the semantic content of two JSON documents, not their text representation.
The comparator parses both JSON inputs into their data structures before comparing. Key order is irrelevant — {"a":1,"b":2} and {"b":2,"a":1} are treated as identical. Formatting is irrelevant — minified and beautified versions of the same JSON are identical. Only the actual data matters.
Every detected difference is classified into one of four categories:
null. A special class of modification worth calling out separately because type changes often indicate a bug, not a configuration change.For every difference found, the comparator reports the full dot-notation path to the changed field:
This eliminates the need to hunt through nested structures manually — you know exactly where every change is.
Arrays are the trickiest part of JSON diffing, because arrays are ordered and their elements don't have keys. Our comparator offers two modes:
Array elements are compared by position. [1,2,3] vs [1,3,2] shows two changes (positions 1 and 2 swapped). Use this when array order is semantically meaningful — lists of steps, ordered results, priority queues.
Array elements are compared by value regardless of position. [1,2,3] vs [1,3,2] shows no differences. Use this when array order is irrelevant — tag lists, permission sets, feature flags.
When comparing real-world JSON from different environments or timestamps, some fields are expected to differ — updatedAt, requestId, sessionToken, correlationId. Our comparator lets you specify fields to ignore by key name, so noise from known-different fields doesn't obscure the meaningful changes.
Different developers reach for a JSON diff tool in different situations. Here are the scenarios that drive the most usage — and what makes structural JSON comparison essential in each one.
You've deployed a new version of a service. A downstream consumer is reporting unexpected behavior. You need to know: did the API response shape change? Did a field disappear? Did a value type change from string to number?
Why it matters: API contract changes are a leading cause of integration bugs, and they're easy to introduce accidentally.
Configuration drift is one of the most insidious sources of environment-specific bugs. Staging behaves differently from production. Tests pass locally but fail in CI.
Why it matters: Even a single field difference — a feature flag that's true vs false, or a timeout that's 30 vs "30" — explains behavior that would otherwise take hours to debug.
Reviewing a pull request that changes how data is structured — a database migration, a serializer update, an API version bump — is much easier with a JSON diff. Compare example JSON directly rather than trying to reconstruct the data shape from code diffs alone.
Your test expected this response. It got this other response. The assertion failure message tells you they're different but doesn't tell you how. Paste expected and actual JSON into the comparator and debug in seconds instead of adding console logs.
After migrating data from one system to another (database schema updates, ETL pipelines), verifying that a sample record looks identical structurally across the migration is crucial validation.
A third-party API your application depends on has updated. The documentation says it's backward compatible. Is it? Compare a response captured before the update with one after to verify nothing breaks your integration.
Our online tool is the fastest way to compare JSON on demand. For systematic, automated JSON comparison in CI/CD and test suites, here's how to integrate JSON diffing into your development toolchain:
// Using the 'deep-diff' library
const { diff } = require('deep-diff');
const result = diff(objectA, objectB);
if (!result) {
console.log('Objects are identical');
} else {
result.forEach(change => {
console.log(`${change.kind} at ${change.path?.join('.')}`);
// N: new (added), D: deleted, E: edited, A: array change
});
}# Using deepdiff
from deepdiff import DeepDiff
diff = DeepDiff(obj_a, obj_b, ignore_order=True)
if not diff:
print("Objects are identical")
else:
print(diff.to_json(indent=2))# Compare two JSON files, showing keys present in file2 but not file1 jq -n --argfile a file1.json --argfile b file2.json \ '($b | keys) - ($a | keys)' # Full structural diff using diff + jq formatting diff <(jq -S . file1.json) <(jq -S . file2.json)
// Jest's toEqual performs deep // structural comparison expect(actualResponse).toEqual( expectedResponse ); // On failure, Jest shows a // detailed diff of exactly // what's different
import unittest
class ApiTest(unittest.TestCase):
def test_response_structure(self):
# assertEqual on dicts shows
# deep diff on failure
self.assertEqual(
actual_response,
expected_response
)JSON comparison is straightforward in concept but there are several common mistakes that lead to false positives, missed differences, or unreliable results:
JSON.stringify(a) === JSON.stringify(b) fails when objects have the same data but different key ordering. Always parse first, then compare structurally.
{"timeout": 30} and {"timeout": "30"} are semantically different in almost every context — one is a number, one is a string. Many languages will silently coerce types, masking this difference in application code. Your diff tool should flag type changes explicitly.
Not every array is an ordered list. Permission sets, tag lists, and category arrays often have no meaningful order. Comparing them in ordered mode generates false positive differences. Know whether your arrays are ordered or unordered before choosing comparison mode.
Timestamps, request IDs, session tokens, and other ephemeral values differ between any two JSON objects captured at different times. Failing to exclude these fields turns every comparison result into noise that obscures meaningful differences.
Floating point numbers, date formats, and URL encoding can produce apparent differences that are semantically equivalent. 1.0 vs 1, "2024-01-15" vs "2024-01-15T00:00:00Z" — decide upfront how your comparison should handle these cases.
Text comparison compares raw character sequences — it's sensitive to formatting, key ordering, and whitespace. JSON comparison parses both documents into data structures and compares their semantic content. Two JSON objects that are text-different but data-identical (different key order, different indentation) will show no differences in JSON compare and hundreds of differences in text compare. For JSON, always use a JSON-aware diff tool.
Not semantically — the JSON specification does not define an ordering for object keys. Our comparator treats {"a":1,"b":2} and {"b":2,"a":1} as identical. However, if you're comparing JSON for exact string equality (such as comparing signed payloads or checksums), key order in the serialized form matters and you should use text comparison instead.
By default, arrays are compared element-by-element in order — position 0 against position 0, position 1 against position 1, and so on. If you want to compare arrays without regard to element order (for sets, tag lists, permission arrays), switch to unordered comparison mode. The choice depends on whether order is semantically meaningful in your specific array.
Yes. If the two JSON objects have completely different structures, the diff will show all keys in the left object as removed and all keys in the right object as added. There's no requirement for the two inputs to have similar structures.
Yes. Use the field exclusion option to specify key names that should be ignored during comparison — such as `updatedAt`, `requestId`, `sessionToken`, or any other fields you know will differ between the two objects for reasons unrelated to the comparison you care about.
Type changes are flagged as a special category of modification — distinct from a simple value change. {"count": "5"} vs {"count": 5} shows a type change from string to number at the count field. Type changes are often bugs — a serializer silently changing a type — and deserve explicit highlighting.
Yes. The comparator handles arbitrary nesting depth. Differences in objects nested five or ten levels deep are reported with their full dot-notation path, so you can locate them instantly without navigating through the structure manually.
There is no hard size limit. Comparison runs in your browser and handles large JSON documents efficiently. For very large files (several MB), use the file upload option rather than pasting for better performance.
The online tool is for manual, on-demand comparison. For automated API response comparison in test suites, integrate a JSON diff library into your test framework — `deep-diff` for JavaScript, `deepdiff` for Python, or use your test framework's built-in deep equality assertion (Jest's `toEqual`, pytest's `==` with dict comparison).
A type change means a key exists in both objects but the value's data type is different — for example, a string in one object and a number in the other, or a boolean becoming `null`. Type changes are common when APIs change serialization behavior, when configuration values are read from environment variables (which are always strings) and compared to typed values, or when data migration scripts don't preserve types correctly.
Paste both JSONs above and know in seconds what's different, what's missing, and what changed — so you can stop comparing manually and start fixing what actually matters.