JSON Diff / Compare Tool

A text diff (like this site's own Text Diff Checker) compares two blocks of text line by line - it has no idea what JSON is, so reformatting a document, reordering its keys, or changing indentation shows up as a wall of changed lines even when the underlying data is identical. This tool parses both sides as actual JSON first, then compares the resulting structures - so {"a":1,"b":2} and a pretty-printed version with "b" listed before "a" are correctly reported as having zero differences. Only real additions, removals and value changes are shown.

'Changed' means the value at that path is still the same JSON type but has a different value - a number that went from 5 to 6, or a string that went from "draft" to "published". 'Type-changed' means the type itself is different - a field that used to be a boolean is now a string, or a number became null. That distinction matters a lot in practice: a type change is far more likely to break code that reads that field (a function expecting a boolean will misbehave if it suddenly gets a string), so this tool flags it separately rather than lumping it in with an ordinary value update.

Item by item, in order: index 0 against index 0, index 1 against index 1, and so on, with any extra items at the end of the longer array reported as added or removed. This is simple and predictable, but it means inserting a new item in the middle of an array will make every item after it look changed, even if they're actually identical - because they've all shifted by one position. That's a real limitation of position-based array comparison in general (not just this tool), so for arrays where item order can shift, it often helps to look at whether the reported 'changed' items are genuinely different or just displaced.

The exact parse error your browser's own JSON parser produces is shown under that textarea, instead of silently failing or showing a stale result. Common causes are a trailing comma after the last item in an object or array (valid in JavaScript object literals, invalid in JSON), missing quotes around a key name, or a stray comment - JSON has no comment syntax at all, unlike JavaScript or JSON5.

Yes, and it's one of the most useful things to use it for: paste a response captured before a change and one captured after, and every field that was added, removed, or - critically - changed type gets flagged. A field silently changing from a number to a string, or a boolean to null, is exactly the kind of breaking change that's easy to miss by eye in two large payloads but shows up immediately here as a distinct 'type-changed' entry.

No, never - two JSON objects with the same keys and values are treated as identical regardless of what order those keys are written in, since JSON itself doesn't define any meaning for key order. This also means a minified, single-line JSON document and a nicely indented, multi-line version of the exact same data will correctly show zero differences here.

No. Both documents are parsed and compared entirely in your browser using plain JavaScript - nothing is uploaded to a server, so it's safe to paste real API responses, configuration files, or other data you wouldn't want leaving your machine.

It handles typical API responses and config files - anywhere from a few lines to several thousand - comfortably, since the whole comparison runs synchronously in your browser tab. For genuinely huge documents (tens of megabytes), the recursive walk over every key and array index can get slow enough to notice; if that happens, it usually helps to trim both documents down to just the section you actually care about before comparing.

They answer different questions and work well together rather than as substitutes. A source-control diff is textual - it shows you the exact lines that changed in the file, including reformatting, reindentation, or a linter reordering keys, none of which this tool considers a real difference. This tool answers a narrower, often more useful question after a formatter or auto-generated file has touched something: did the actual configuration change, or did only its formatting change? Running both together on a suspicious commit is a fast way to tell 'nothing to worry about, just reformatted' from 'this genuinely changed behavior'.

It still works - if the very top level itself differs in shape (an object on one side, an array on the other, or a primitive value versus either), that's reported as a single root-level difference rather than the tool trying to force a comparison that doesn't make sense. The same logic that flags a nested field's type change applies at the root: it's treated as the most fundamental kind of difference two JSON documents can have.

Only as a side effect - each side is parsed to compare it, so an invalid document shows a parse error rather than silently comparing nothing. But this tool's job is comparing two documents that are each already valid JSON, not pretty-printing or auto-fixing a single one. If you need to validate, reformat, or minify one JSON document on its own, this site's JSON Formatter & Validator is built specifically for that and is a natural first step before pasting a document in here.