1. Parsing and value types
Each input must be one complete JSON value: object, array, string, number, boolean, or null. Object member order is ignored because it does not change the JSON value. Array order is significant unless you add a path-specific rule.
Numbers are parsed with their original decimal representation. This avoids silently rounding large integers through JavaScript’s ordinary binary floating-point number type. A missing member and a member whose value is null remain different.
For prototype-safety, objects containing the exact member name __proto__ are rejected with an explicit error. This is a documented compatibility limit rather than silently treating that member as ordinary data.
2. Default comparison
Objects are compared recursively by member name. Arrays are compared by position. Scalars are compared by both type and value. The result distinguishes added, removed, modified, and type-changed values.
{"enabled": false} ≠ {"enabled": "false"}
boolean → string3. Match arrays by identity
At a specific JSON Pointer, you may match objects by a scalar key such as id, sku, or name. The key must exist and be unique on both sides. Suggested keys are evidence, not automatic decisions; you must confirm one.
If an item is not an object, the identity is missing or complex, or a value is duplicated, the rule stops and the result is marked unresolved. PayloadPair does not silently fall back to position. Successful records display both source indices and the identity used to pair them.
4. Treat arrays as unordered multisets
An unordered rule compares canonical JSON values while preserving duplicate counts. Therefore ["a","a"] is not equal to ["a"], even though order is ignored.
5. Ignore rules and numeric tolerance
Exact-path rules use the escaping rules from JSON Pointer (RFC 6901). A key-name rule is deliberately broader: it ignores every member with that name. Rule coverage and ignored-change counts remain visible.
Numeric tolerance affects the filtered review only. It uses an absolute difference and applies only when both values can be represented as finite numbers for the tolerance calculation. Exact equality never uses tolerance.
6. Exact patch versus semantic report
The semantic report answers, “What changed under my review rules?” The patch answers, “What exact operations transform the original JSON into the modified JSON?” These are separate artifacts.
Ignore rules, array matching, and tolerance never alter the exact patch. PayloadPair generates add, remove, and replace operations using JSON Patch (RFC 6902) paths, applies them to a clone of the original value, and enables export only if the result exactly reproduces the modified value.
7. Limits and failure behavior
Comparison runs in a browser worker. The file picker rejects files larger than 5 MB per side, visible changes stop at 2,000 by default, and recursion stops after 128 levels. Browser memory, device speed, and pasted input can impose lower practical limits.
Exact patch export has separate safety bounds: it is disabled above 10,000 operations, for inputs larger than 10 MB combined, or when the serialized patch would exceed 5 MB. The semantic review remains available when patch export reaches one of those limits.
These safeguards bound work; they do not prove that every device can handle a particular payload size. When a limit or ambiguity is reached, PayloadPair reports it rather than presenting a silent partial result as complete.
Standards and public fixtures
The engine’s public cases exercise JSON semantics described in RFC 8259, pointer escaping from RFC 6901, and patch paths from RFC 6902. See the conformance page for the versioned case list and downloadable corpus.