JSON Merge Tool
Combine two JSON values with explicit rules for collisions, arrays, and nulls.
Values from this side remain unless the selected merge policy replaces or combines them.
This side supplies added keys and the competing value when a path exists on both sides.
Choose what a collision means
Output
The selected merge result or report is shown as text, not executed content.
Choose the merge rules and run the merge to see the result.
There is no single universal “deep merge” rule
JSON defines objects, arrays, and primitive values, but it does not define a general-purpose operation for combining two arbitrary JSON documents. Libraries differ on whether nested objects recurse, whether arrays replace or append, what null means, and which side wins when types differ. The settings above make those choices visible instead of hiding them behind one unexplained merge button.
Deep and shallow merges answer different questions
A shallow merge only examines members at the current object level. If both sides contain a nested object under the same key, that nested object is treated as one competing value. A deep merge descends into nested objects and only resolves a conflict when it reaches values that cannot be recursively combined under the selected rules.
Arrays are handled by their own policy even during a shallow merge. That distinction matters because an array is ordered data, not an object with mergeable member names. “Merge by index” assumes corresponding positions describe corresponding things; it is inappropriate for arrays whose order can change independently.
This is deliberately not JSON Merge Patch
RFC 7396 defines JSON Merge Patch for describing changes to a target document, especially in HTTP PATCH workflows. Its rules are specific: an object patch recurses into object members, a null patch member removes that member, and a non-object patch replaces the target value. The configurable deep, shallow, array, and keep-both behaviors here are broader comparison-and-combination rules, so the output should not be labelled application/merge-patch+json. RFC 7396
Conflict paths are JSON Pointers, not property expressions
Report paths escape ~ as ~0 and / as ~1, following JSON Pointer syntax. The root pointer is the empty string, displayed here as “(root)” so it is not confused with /, which actually addresses a member whose name is empty. RFC 6901
JSON that parses can still be unsafe to rewrite
Duplicate object names and precision-sensitive numbers are checked before either input is merged. Without that check, JavaScript parsing can collapse duplicate names or round a large numeric token before the merge logic ever sees it. The merge also writes object properties with data-property semantics so names such as __proto__ remain ordinary JSON keys rather than altering an intermediate object's prototype.
RFC 8259 recommends unique object member names and describes number-range interoperability limits. If exact decimal digits are identifiers or monetary values that must not be rounded, use strings or a decimal-aware pipeline instead of a generic JavaScript-number merge. RFC 8259
Know what the counters do and do not prove
Added-key and overwrite counts describe decisions made by this merge implementation; they are not a semantic validation of your configuration or API contract. A technically clean merge can still be wrong for the application if two arrays should have been keyed by an ID, if null has domain meaning, or if one side belongs to a different schema version.
Browser limits
Each input is capped at 1,500,000 characters and 100 nested JSON levels. The limits are there to keep recursive merging and report generation responsive. Large repository configuration sets are better merged in code where tests, schemas, and version control can verify the result.