JSON Diff

About the JSON diff tool

This tool compares two JSON documents structurally — by meaning, not by line — and shows exactly which nodes differ. Paste the original on the left, the new version on the right, and hit Compare. Because both sides are parsed into real object trees first, differences that are purely cosmetic (whitespace, indentation, key order) never show up as changes: only genuine added, removed, or altered values count.

How to use it

Load each side with the Sample button, a file paste, or by typing directly. ThePaste button copies the left document into the right panel, which is handy when the new version is a small edit of the old one — paste, tweak, compare. Results render in two views: Tree mirrors the document structure side by side with differences highlighted in place, while List flattens every difference into a single scannable list with its full path — faster to read when there are many changes scattered through a large document. Search narrows both views to matching keys or values, and Expand all / Collapse all control how much of the tree is visible at once.

Reading the highlights

Both documents render as full trees, side by side and resizable by dragging the center divider, with the exact node that differs highlighted in place — green for something only present on the right (added), red for something only present on the left (removed), amber for a value that changed. The change counters above the output summarize all three categories so you can gauge blast radius before reading a single diff. A dashed amber marker appears on any collapsed container that has a change somewhere inside it, so collapsing a branch never hides that something underneath changed.

Why structural beats line-by-line

A text diff treats JSON as lines; reorder two keys or reformat the indentation and every line lights up even though nothing changed semantically. A structural diff parses both documents first, so formatting noise is invisible and the output contains only real differences: a key present in one version and missing in the other, an array element that changed type from string to number, a nested object that gained a field. That distinction matters most when machines produced the files — different serializers pretty-print differently, but the data they encode may be identical.

Everyday scenarios

Typical uses: verifying that an API refactor returns identical payloads between staging and production, spotting config drift between two deployments, reviewing what a webhook payload gained when a provider ships a new field, checking that a migration preserved data, or confirming your bug fix changed only the value it was supposed to. For contract testing, diff last release's saved response against the current one and read the counters as a change report.

Tips for cleaner diffs

A little preparation makes the output dramatically easier to read. If the two documents come from different serializers, run both through the formatter'sSort keys first — key order is then guaranteed identical, so every highlighted difference is a real one. When array order doesn't matter in your domain (a set of tags, an unordered list of records), sort the arrays by a stable key before comparing; otherwise a re-ordered list reports as many changes as it has elements. And when you only care about one subtree, diff the whole document once to find where changes cluster, then paste just that object on both sides for a focused second pass — the counters reset and the noise is gone.

Related: prepare and inspect either side of the comparison with the JSON formatter — sorting keys on both sides before comparing makes the output even cleaner — convert the result to CSV,YAML,TypeScript, orJSON Schema, or diff XML configuration with the XML formatter.