JSON Object Merger

1. 1Add your documentsDrop up to five .json, .jsonc, .jsonl or .ndjson files, or click Paste JSON to type a document in. Order matters — later documents win where they disagree — and the arrows on each row change it.
2. 2Choose how objects combineDeep merge combines nested objects recursively. Shallow merge combines only top-level keys, replacing nested objects whole. Set the null policy if an explicit null should not erase an existing value.
3. 3Choose how arrays combineReplace keeps the last array, Concatenate joins them, Union joins them and drops duplicates, and Merge by key combines records that share a key such as id.
4. 4Merge and reviewPress Merge. The conflict report lists every path where a later document overwrote an earlier value, with both values, and the input report shows duplicate keys and precision warnings found in each source.
5. 5Download or copyPick an indent, or NDJSON when the result is an array, then download or copy. Change any setting afterwards and the result is marked stale until you re-apply it.

Merge up to five JSON documents into one. They combine in the order you put them in, so later documents win where they disagree, and the arrows on each row change that order. Any JSON root works — objects, arrays and primitives alike. Nested objects can merge recursively or be replaced whole, arrays have four strategies of their own, and every value that gets overwritten is written down so the result is something you can check rather than trust.

• Any number of documents, in any order — Drop files, paste text, or both. Reorder rows to change which document wins. Five documents on the free plan, and the order is the tool's one ordering guarantee.
• Deep or shallow, and four array strategies — Objects merge recursively or only at the top level. Arrays replace, concatenate, form a de-duplicated union, or merge record by record on a key field.
• A conflict report, not just a result — Every path where a later document replaced an earlier value, with both values and the document that won. No other online JSON merger publishes one.
• It reads the JSON you actually have — Comments and trailing commas, NDJSON, UTF-16, byte order marks. Each one is a file that a strict parser calls broken and every editor shows as fine.

Powered by optimised processing algorithms.

This is the single decision that changes the result most, and the two answers are genuinely different rather than one being better.

Shallow merge combines only the top level. If a key exists in both documents, the later value replaces the earlier one completely — and "completely" includes nested objects, so a base object with ten nested keys is gone the moment a later document mentions that key at all. Deep merge instead descends into nested objects and combines them key by key, so an override only touches the keys it actually names.

Merging {"server": {"host": "localhost", "port": 8080}} with {"server": {"port": 9090}} gives {"server": {"port": 9090}} under shallow merge — the host is gone — and {"server": {"host": "localhost", "port": 9090}} under deep merge. Deep is the default here because layering configuration is what people come to a merger for, and it is what lodash.merge and every comparable library do.

Deep merge has nothing to say about arrays: two arrays are not two objects, and there is no single correct way to combine them. Most merge libraries quietly pick one behaviour and never mention it. This tool asks.

• Replace — The later array wins outright. This is what deep merge conventionally does and what most libraries do without telling you. It is the default here.
• Concatenate — Every item from both arrays, in order, duplicates included. Right for logs, event streams and anything where each entry is its own record.
• Union — Both arrays joined, then duplicates removed by comparing structure rather than identity — so {"a":1,"b":2} and {"b":2,"a":1} count as the same item.
• Merge by key — Treats both arrays as record sets and combines records that share a key field. Covered on its own below.

The array strategy applies wherever two arrays meet, in shallow mode as well as deep. Making it inert in shallow mode would leave a control on screen that silently does nothing.

Merge by key is the strategy that turns two arrays of records into one. Set the key field — id by default — and matching records combine field by field instead of one array replacing the other.

• Matching records merge — A record in a later document whose key matches an earlier one is merged into it using the same object rules as everywhere else, so its fields are added rather than replacing the whole record.
• New records are appended — A record whose key is not already present is added at the end, keeping the earlier document's order intact.
• Records without the key are left alone — Items that are not objects, or objects that do not carry the key field, are appended untouched rather than being guessed at.
• Types are part of the key — The number 1 and the string "1" are different records and do not join. Treating them as equal is the classic join bug, and it produces a result that looks perfectly reasonable and is wrong.

JSON has no undefined, so null carries two meanings at once: it is a real value, and it is the only way a configuration layer can say "unset whatever was here". Both readings are legitimate and no library can tell which you meant. By default an overlay null overwrites, because null is a value. Switch the null policy to Ignore and a null in a later document is skipped entirely, so it can never erase something a base document set. The merge report counts how many nulls were ignored, so choosing the wrong one is visible rather than silent.

JSON objects have no formally defined key order, but every parser and every serializer in practice preserves the order keys were written in — which means the order shows up in your version control diff. By default the merged result keeps the base document's order and appends new keys from later documents at the end, so a merge produces the smallest possible diff. Sort A to Z instead when you want output that is stable regardless of how the inputs happened to be written, which is what you want for a file that several tools regenerate.

A merger that only gives you the merged file is asking you to take its word for it. This one records every place a value was lost.

A conflict is any path where a later document replaced an earlier value rather than merging into it: a scalar overwriting a scalar, an array replacing an array, or an object replacing an object under shallow merge. The report gives the path, the value that was replaced, the value that replaced it and which document won. Values that were merged rather than replaced are not conflicts, and neither is a later document writing the identical value — both would be noise. Alongside it, the input report lists what was found in each source document before merging began.

Two things every JSON parser throws away silently, both of which change what your merged file contains.

• Duplicate keys — {"a": 1, "a": 2} is valid JSON and every parser keeps the last one, discarding the fact that there were two. If the duplicate was a mistake, the merge you audit is not the merge you wrote. Each source document reports how many duplicate keys it contained and where.
• Numbers that cannot round-trip — JavaScript numbers are IEEE-754 doubles and carry 15 to 17 significant digits. A 64-bit database id such as 9007199254740993 becomes 9007199254740992 in every JSON parser in every browser, so the merged file contains a different id from the input. There is no fix inside JSON's data model, so the tool reports it instead of pretending otherwise.

Strict JSON and the JSON people actually have on disk are not the same thing. Four differences account for almost every file that "is valid everywhere except in my program".

• Comments — tsconfig.json, .eslintrc.json and every devcontainer.json carry // and /* */ comments. JSON.parse rejects them. They are recognised, counted and merged.
• Trailing commas — The other half of hand-edited config. Also rejected by JSON.parse, also handled here.
• NDJSON and JSON Lines — One document per line, which is how log exports and streamed API results arrive. Detected automatically and read as an array, and available as an output format when the merged result is an array.
• Byte order marks — PowerShell writes UTF-16 with a mark by default and .NET writes UTF-8 with one. Decoded as plain UTF-8, a UTF-16 file becomes nonsense and every parser blames character one. The mark is read first and decides the encoding.

Almost every JSON merge is one of a handful of jobs, and knowing which one you are doing usually settles the settings.

• Layer configuration — A base config, then environment overrides, then local ones. Deep merge, source key order, and Ignore nulls if your override files use null as a comment.
• Combine API payloads — Several responses into one object. Deep merge, and Merge by key if the payloads carry record arrays that should line up on an id.
• Join record sets — Two exports of the same entities with different fields. Merge by key on the shared identifier turns them into one complete set.
• Consolidate translations — Locale files split across teams or features. Deep merge with Sort A to Z gives a stable file that diffs cleanly on every regeneration.
• Assemble test fixtures — A default fixture plus per-case overrides, so each test states only what makes it different.

• Merge mode — Deep merges nested objects recursively. Shallow merges top-level keys only and replaces nested objects whole.
• Arrays — Replace, Concatenate, Union (duplicates removed) or Merge by key.
• Key field — Which field identifies a record for Merge by key. Defaults to id. Matched by type as well as value.
• Nulls — Overwrite, so an explicit null replaces a value, or Ignore, so it never erases one.
• Key order — Source keeps the base document's order and appends new keys. A to Z sorts every object for a stable diff.
• Indent — Minified, 2 spaces, 4 spaces or a tab.
• Output — JSON, or NDJSON when the merged result is an array.
• Accept comments and trailing commas — On by default. Turn it off to have the tool hold every document to strict JSON.
• Reset — Clears every document, the result and all settings back to their defaults.

The free plan takes five documents, up to 10 MB each and 30 MB in total. The total is the number that usually binds, because a merge holds every input plus the merged result in memory at once. Every control that decides whether the merge is correct is free — both modes, all four array strategies, the key field, the null policy, key ordering, all four indents, both output formats, and both reports. Pro raises the scale only: more documents, your device's own ceiling instead of a fixed cap, and a batch delivered as a single archive.

• JSON Formatter
• JSON Validator
• JSON Sort Keys
• JSON Diff
• JSON Minifier
• JSON Remove Keys
• JSON Viewer
• JSON Escape
• JSON to YAML
• JSON to XML
• CSV to JSON
• Excel to JSON
• JSON Tools