JSON Diff Comparator
Deep-compare two JSON objects and visualize added, removed, and changed keys.
About this tool
Paste two JSON documents into the side-by-side panes and instantly see a color-coded diff: green for added keys, red for removed keys, yellow/orange for changed values, and gray for unchanged content. Switch between side-by-side and unified diff views, navigate between differences with prev/next buttons, and see a summary count of all changes.
How to use
- 1 Step 1: Paste your original JSON into the left pane and the modified JSON into the right pane.
- 2 Step 2: Click 'Compare' — the diff is computed instantly and highlighted in both panes.
- 3 Step 3: Check the summary bar for a count of added, removed, and changed keys.
- 4 Step 4: Use the Prev / Next buttons to jump between each difference, or toggle to unified view.
What a structural JSON diff actually compares
A plain text diff treats JSON as lines of characters, so reordering keys or re-indenting a file lights up as a sea of changes even when nothing meaningful moved. A structural diff — what this tool performs — parses both inputs into real objects first, then walks the two trees key by key. The result tells you which keys were added, which were removed, and which kept the same key but changed value. Because it compares the parsed structure rather than the raw text, whitespace and key order are irrelevant; only genuine differences in data appear.
How the comparison algorithm works
The diff is recursive. At each node it first checks that the two values are the same kind of thing — an object versus an array versus a primitive. If the types differ, the whole node is reported as changed. For two objects, it gathers the union of keys from both sides: a key present only on the right is added, a key present only on the left is removed, and a key in both is compared by descending into it. For primitives (strings, numbers, booleans, null), it uses strict equality, so 5 and "5" are reported as different because one is a number and one is a string. Every difference carries a dotted path like address.city so you can see exactly where in the tree it lives.
A worked example
Load the built-in sample and you compare these two objects:
- Left:
{ name:"Alice", age:30, role:"admin", tags:["a","b"], address:{ city:"Seoul", zip:"12345" } } - Right: the same, but
age:31,role:"user",tags:["a","b","c"],address.city:"Busan",address.zip:"54321", plus a newemailkey.
The summary reports 1 added (email), 0 removed, and several changed values: age, role, address.city, address.zip, and tags.2 (the new third array element). Notice how nested paths are fully qualified, so a change buried inside address is just as visible as a top-level one.
Side-by-side versus unified view
The side-by-side view renders both documents as formatted JSON with color cues — added keys glow green on the right, removed keys glow red on the left, and changed values are highlighted amber on both panes — so you read the two states in context. The unified view collapses everything into one list grouped by change type: a block of + added lines, a block of - removed lines, and a block of ~ changed lines that print the old and new value together. Side-by-side is best for reviewing structure; unified is best for copying a concise changelog of exactly what differs. The prev/next buttons let you step through differences one at a time.
The array caveat you must know
Arrays are compared strictly by index, not by content matching. If you insert one element at the front of a list, every following element shifts by one position, so the diff reports them all as changed even though their values merely moved. This is the single most common source of confusing output. When you expect a small change but see a cascade of differences in an array, suspect an insertion or deletion near the top. For order-independent data, sort both arrays the same way before comparing, or compare the objects by a stable key rather than by position.
Practical use cases
- API regression checks: capture a known-good response and diff it against a new build to catch unintended field changes.
- Config drift: compare a staging config against production to spot a setting that was changed on one but not the other.
- Reviewing edits: paste the before and after of a JSON file you hand-edited to confirm you changed only what you intended.
- Debugging serialization: verify that data survives a round trip through encode and decode unchanged.
Tips and privacy
If either input fails to parse, the tool shows the parser's error message with the approximate location, so fix the syntax — a trailing comma or unquoted key is the usual culprit — before comparing. Because JSON object key order does not affect the structural diff, you do not need to sort keys first; identical data in different orders correctly reports zero differences. All parsing and comparison run entirely in your browser, so the documents you paste never leave your device — safe for diffing configuration or response data that contains secrets.