Comparar JSON
JSON Diff is a client-side semantic comparison engine that parses JSON payloads into Abstract Syntax Trees, completely ignoring key ordering and insignificant whitespace. It features configurable array matching by primary key, distinct type-shift classification, Web Worker execution handling up to 100 MB of JSON without freezing the tab, bi-directional RFC 6902 JSON Patch export and application, and an opt-in three-way merge that joins two branches against a common ancestor with per-path conflict resolution.
A interface desta ferramenta está em inglês.
Semantic left vs right compare — key order and whitespace ignored.
No differences to show
Paste two JSON documents above. Comparison runs in a Web Worker, so the page stays responsive even on a multi-megabyte payload.
O guia abaixo está disponível apenas em inglês.
How does JSON Diff work?
Standard line-by-line diff tools (like classic Unix diff) fail on JSON because they compare serialized text instead of semantic data. In JSON, key order is explicitly arbitrary according to RFC 8259: {"a":1,"b":2} and {"b":2,"a":1} represent identical objects, yet textual diff engines flag them as contradictory lines.
The ToolsByUs diff engine solves this by operating on parsed Abstract Syntax Trees (AST) inside an isolated Web Worker. It normalizes object keys lexicographically and implements three configurable array matching algorithms:
- Index Matching: Aligns array elements strictly by ordinal position (default for primitive lists).
- Key Matching: Correlates collection entities by an immutable identifier (e.g.
idoruuid), ensuring reordered list items are detected as modifications or moves rather than spurious delete-and-add churn. - Structural Similarity: Uses bipartite maximum-weight matching to align objects with highest field correspondence.
Scalar type changes (such as changing a string "42" to a numeric 42) are recognized as distinct TYPE_CHANGE events rather than destructive replacement cycles.
Left vs Right Sample
// Left:
{"id": 1, "tier": "free", "name": "Alpha"}
// Right:
{"name": "Alpha", "id": 1, "tier": "pro"}Example output
// Semantic Diff Result: - tier: "free" (Removed) + tier: "pro" (Added) = id: 1 (Unchanged) = name: "Alpha" (Unchanged, key order ignored)
What does a JSON diff actually return?
Note what is missing from the patch: id and name were written in a different order in the two documents, and key order is not a change, so no operation is emitted for it.
Document A
{
"id": 42,
"name": "Ada",
"tags": ["math", "code"],
"active": true
}Document B
{
"name": "Ada Lovelace",
"id": 42,
"tags": ["math", "code", "analysis"],
"active": false
}RFC 6902 patch
[
{
"op": "replace",
"path": "/active",
"value": false
},
{
"op": "replace",
"path": "/name",
"value": "Ada Lovelace"
},
{
"op": "add",
"path": "/tags/2",
"value": "analysis"
}
]Three operations for three real differences. Array position matters — /tags/2 is an add at index two — because arrays are ordered and objects are not.
What options and edge cases does JSON Diff support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| Key Order Invariance | Invariant | Always On | Object keys are compared as mathematical sets. Differing key sequences produce zero diff churn. |
| Array Match: index | Mode | Default | Matches items strictly by zero-based index. Ideal for simple scalar arrays [1, 2, 3]. |
| Array Match: key | Mode | 'id' | Matches object items across arrays by user-defined primary key property. Prevents false additions on reorder. |
| Array Match: similarity | Mode | Score > 0.4 | Heuristic structural matching based on shared keys and primitive scalar equality. |
| Type Change Class | Category | Active | Tagging type transitions ('1' -> 1) as distinct TYPE_CHANGE operations instead of delete+add. |
| Memory Ceiling | Limit | 100 MB | Explicit in-worker payload ceiling guarding against browser tab out-of-memory crashes. |
| Three-way Merge | Mode | Opt-in | Base + Ours + Theirs merged in-page (8 MB ceiling); conflicts default to the ancestor value and re-resolve live per path. |
Frequently asked questions
Why doesn't key order matter in JSON diffing?
According to the official JSON specification (RFC 8259 Section 4), JSON objects are collections of unordered zero or more name/value pairs. Because JSON encoders (such as Python dictionaries or Go map iteration) serialize keys in non-deterministic orders, semantic diffing must normalize key orders to eliminate false differences.
How does matching arrays by key work?
When dealing with arrays of database models or API records, items often change order or are deleted. By specifying a primary key like 'id' or 'uuid', the diff engine matches left and right objects having the same key value regardless of array position, accurately highlighting field mutations instead of reporting full array replacements.
Can I generate an RFC 6902 JSON Patch from this diff?
Yes. ToolsByUs generates compliant RFC 6902 JSON Patch arrays (with operations 'add', 'remove', 'replace', and 'move') that can be copied with one click or applied directly to documents. The patch is guaranteed to round-trip: applying the generated patch to your original document produces the exact target document.
How does the three-way merge handle conflicting edits?
Switch to 'Three-way merge' and provide the common ancestor in Base plus both branch documents. Changes only one side made merge automatically. Where both sides touched the same path, the engine records a conflict and the merged output uses the base value until you choose Ours, Theirs or Base for that path — every choice re-resolves the output instantly, entirely in your browser.
Is my JSON payload sent to any backend server?
No. ToolsByUs is a zero-backend static website. Parsing, AST traversal, and diff generation execute 100% inside your browser's dedicated Web Worker thread. Network requests are completely disabled while documents are loaded, verified by strict automated E2E tests.
How large of a JSON document can I diff without freezing the tab?
Because all heavy parsing and traversal run in a Web Worker and rows are rendered using virtualized scrolling (only elements visible in your viewport exist in the DOM), the interface stays responsive on documents up to the worker's 100 MB ceiling. A 50 MB pair still takes tens of seconds of real work — the difference is that you can scroll, type and cancel while it runs, instead of watching a frozen tab.