JSON Object Diff

1. 1Add the first documentPaste JSON into the left box, or drop a .json file onto the drop area. Drop two files at once and they are paired automatically — names like users.before.json and users.after.json are matched, and the older side is placed on the left.
2. 2Add the second documentPaste or drop the second document into the right box. Use Swap if the two sides ended up the wrong way round.
3. 3Read the differencesThe comparison runs as you type. Switch between side-by-side, inline and by-path views; unchanged sections stay collapsed until you open them, and the next and previous buttons jump between changes.
4. 4Tune what counts as a differenceIgnore array order, letter case or whitespace; set a number tolerance; name keys or paths to skip; or match array items by an id field so a reordered list reads as reordered rather than rewritten.
5. 5Export the resultCopy the summary, download an RFC 6902 JSON Patch that turns the left document into the right one, or download a Markdown report to paste into a pull request or a ticket.

Find exact JSON changes between two objects, including added, removed, and changed keys, with fast filtering and clear diagnostics. Paste or drop two documents and the comparison runs on your device as you type: every difference is reported by its exact path, arrays are matched element by element rather than dumped as a blob, and the result can leave as a JSON Patch, a Markdown report, or a copyable summary.

• Path-accurate differences — Every change is addressed by a JSON Pointer, so users/1/name means that field of that item and nothing else. A key that literally contains a dot or a slash is escaped rather than blurred into the path around it.
• Three ways to read it — Side by side for scanning, inline for a familiar patch-style view, or a flat list by path for jumping straight to what moved. Unchanged sections stay collapsed until you open one.
• Four kinds of change — Added, removed, changed, and type changed. A value going from "3" to 3 is called out separately, because it is the change most likely to break whatever reads the document next.
• Exports that do something — An RFC 6902 JSON Patch that other tools can apply, a Markdown report for a pull request, or a plain summary for a message. The page it replaces had no export at all.

This is the part that separates a useful JSON diff from a frustrating one. Comparing two arrays position by position works only while nothing has been inserted or removed: add one item at the front of a list of a thousand and every later element lines up against the wrong neighbour, so a one-item change is reported as a thousand.

So the arrays are aligned before they are compared, using whichever of four strategies fits. The one that ran is shown next to the summary, because the first question anyone asks of an array diff is why two particular items were paired.

• By id — Name a field under Match array items and elements line up by its value. A collection that came back from an API in a different order then reads as reordered, with only the genuinely changed record reported. It is only used when every element carries the field and no value repeats — a key that is not unique would produce a confident, tidy, wrong pairing, so it is refused rather than guessed.
• By longest common subsequence — The default. The shared prefix and suffix are matched first, then the middle is aligned so the fewest possible items count as inserted or removed. An insertion is one addition; a deletion is one removal; everything else stays lined up.
• As a set — Turn on Ignore array order and the two lists are compared as unordered collections, so items that only moved are not differences at all.
• By position — The honest answer for two lists with almost nothing in common, where any pairing is arbitrary and pretending otherwise only adds noise.

The default comparison is strict: every value, every type and every array position has to match. Each option below relaxes one specific thing, and the report records which ones were on, so a result can always be read back later.

• Ignore array order — Treat arrays as unordered collections. Useful for tag lists, permission sets and anything whose order carries no meaning.
• Ignore case — Compare strings without regard to capitalisation. Useful for labels and enum values that changed style but not meaning.
• Ignore whitespace — Trim strings and collapse runs of spaces before comparing, so a reflowed description does not read as a rewrite.
• Number tolerance — Choose how close two numbers have to be to count as equal, from exact up to 1. Set it to 0.0001 and float rounding noise disappears while a real price change does not.
• Ignore keys — Name keys — updatedAt, requestId, etag — and they are skipped wherever they appear, at any depth. This is what turns two API snapshots into a readable diff.
• Ignore paths — Skip a specific location rather than a name. Wildcards are supported: /users/*/lastSeen skips that field for every user, and /meta/** skips everything under meta.
• Allow comments and trailing commas — Accept JSONC, so config files can be compared as written. Dropping a .jsonc file turns this on for you.
• Compare as you type — On by default. Turn it off on very large documents if you would rather compare on demand; the button then says how many results are out of date.

Every difference carries an RFC 6901 JSON Pointer — /users/1/name rather than users.1.name. The distinction matters more than it looks, because a path built by joining keys with dots is ambiguous the moment a key contains one.

A document with a key literally named a.b and a document with a nested a containing b produce the same dotted path, so two genuinely different locations claim the same address and neither can be resolved back to a node. A pointer escapes the separator instead of reserving it: ~ becomes ~0 and / becomes ~1, so every path resolves to exactly one place. That is what makes the exported patch applicable, the jump-to-change buttons possible, and the result usable by another tool.

• On screen — Paths are shown in a friendlier form — $.users[1].name — because that is what reads best. The pointer is what gets exported.
• In the patch — Every operation is addressed by its pointer, which is what makes the file a standard RFC 6902 patch rather than something only this tool understands.

A diff is usually evidence for something else — a review, a ticket, a deployment check — so it has to be able to leave the page. Three exports cover the ways that happens, and all three are available on the free plan.

• JSON Patch (RFC 6902) — A standard list of add, remove and replace operations that turns the left document into the right one. Array operations are ordered so that indices stay valid as the patch is applied: everything inside an element first, then removals from the back, then insertions from the front.
• Markdown report — A summary table, the settings that were used, and a row per difference with the path, the kind of change and both values. Values containing a pipe are escaped, so a table row can never split into the wrong columns.
• Copyable summary — A plain-text list with +, - and ~ prefixes, for a chat message or a commit note.
• One ZIP for a batch — With Pro, every comparison in the queue exports its report and its patch into a single archive.

JSON permits an object to declare the same key twice. Every parser in existence accepts it and silently keeps the last value, which means two documents can differ in a key that no comparison could ever see — the difference is gone before the comparison starts.

Both sides are scanned for repeated keys and you are told which key and where. The scan runs after the result appears, so it never delays the answer. Two more quiet cases are handled the same way: numbers are compared by value rather than by how they were written, so 1, 1.0 and 1e0 are one value and -0 equals 0; and object keys are compared as a set, so reordering the keys of an object is not a change.

• Same key twice — Reported as a warning naming the key and its location, on whichever side it appears.
• Numbers written differently — 1 and 1.0 are the same value and are not reported as a change.
• Keys in a different order — Objects are unordered by definition, so a reordered object compares as identical.
• Any root, not just an object — An array, a string, a number, true, false or null at the top level all compare normally.

The tool opens exactly the formats below and refuses everything else at the point you choose the file, rather than letting it reach the parser and fail. A refused file is named, and so is the tool that converts it.

• JSON, GeoJSON, source maps, plain text — .json, .geojson, .map and .txt all open directly. Files are recognised by extension, not by the type your system reports — which is often nothing at all.
• JSONC — .jsonc opens with comments and trailing commas accepted automatically. The option can also be turned on by hand for a .json file that happens to contain them.
• YAML and XML — Refused, with a link to the YAML to JSON or XML to JSON converter. Convert first, then compare.
• CSV and Excel — Refused, with a link to CSV to JSON or Excel to JSON.

The comparison runs off the main thread, so the page keeps responding while it works and Cancel actually cancels — including during the slowest phase rather than only between steps. Progress is real: it counts nodes visited, not seconds elapsed.

The result list is windowed rather than built in full. A comparison producing thousands of differences renders only the rows on screen, which is why a very large diff scrolls smoothly instead of freezing the tab while tens of thousands of elements are created. Unchanged sections are not built at all until you open one.

• As you type — Edits are coalesced into one comparison rather than one per keystroke, and only one runs at a time.
• Cancel — Stops within a fraction of a second, at any point in the run.
• Counts stay exact — Above 100,000 differences the list stops growing but the totals do not, and the page says the list was truncated. A summary that quietly under-reports would be worse than no summary.

A 10 MB pair parses, compares and produces its patch in well under a second, off the main thread, so the page stays responsive while it runs.

Config files, API responses and exported data change between versions, and the interesting part is almost never visible in the raw text. A structural comparison tells you exactly which keys were added, removed or retyped without reading either document, which is what makes it useful in a review, a bug report or an audit.

• Faster reviews — Spot structural changes in configs and payloads without a line-by-line read, and paste the Markdown report straight into the pull request.
• Regression checks — Compare an expected response against an actual one, ignore the fields that always change, and see only what genuinely moved.
• Migrations and audits — Confirm that a transformation kept every field it should have, and produce a patch as the record of what it changed.
• Runs on your device, not our servers — Credentials, customer records and internal payloads are compared where they already are — nothing is uploaded and nothing is stored.

Free is capped on scale, never on function: every comparison option, every view and every single-pair export works on the free plan. Pro raises the ceiling and adds the batch.

• Free — One pair at a time, up to 10 MB per side. All options, all three views, and the JSON Patch, Markdown and summary exports.
• Pro — Documents up to what your device can handle, and up to 50 pairs queued at once — paired by name, with every report and patch in a single ZIP.
• If a file is too large — The refusal says the actual size and the cap, and links to the JSON Minifier — a document pretty-printed at two spaces is often mostly indentation, and minifying it is frequently the whole fix.

• JSON Formatter
• JSON Validator
• JSON Merge
• JSON Minifier
• JSON Viewer
• YAML to JSON