JSON Compare

A JSON compare tool takes two JSON documents and tells you precisely how they differ: which keys appeared, which disappeared, which values changed, and where in the structure each of those things happened.

The important word is data. It does not compare the two files as text. It parses both, then walks the resulting structures together, matching key against key and item against item. That is why re-indenting a file or reordering its properties produces no differences at all — nothing about the data changed, only its spelling.

The result is shown side by side, with each row aligned against its counterpart and marked according to what happened to it:

Four rows, four verdicts: one unchanged, one modified, one removed, one added. Reading that takes a second. Finding the same four facts by scrolling two documents in two windows takes considerably longer, and is much easier to get wrong.

Because “what changed?” is one of the most common questions in software, and JSON is the format most of the answers are written in. Comparing by hand does not scale past a screenful, and comparing as text answers a subtly different question:

• Formatting stops being noise. A file that was re-indented, or written by a different serialiser, shows zero differences instead of hundreds. Only real changes survive.
• You get a count, not an impression. Twelve added keys, five removed, eighteen modified. That is something you can check against what the change was supposed to do.
• Every difference has an address. Each one carries its JSON path, so $.users[2].address.city goes straight into a bug report, a test assertion, or a JSONPath tester if you want to pull the same field out of a third document.
• Type changes surface. An id that quietly became a string, or a number that arrived as null, is exactly the kind of change that passes review and breaks a client. It is reported explicitly here.
• Minified documents stop being opaque. A line diff of two single-line files tells you only that line one differs. A structural comparison pinpoints the character that moved.
• Size stops mattering. Identical branches are skipped rather than walked, so most of a large pair of documents costs nothing to compare.

Everything below runs in your browser. There is no upload step, no queue and no account.

Side-by-side diff

Both documents are drawn from a single merged tree, so the two columns cannot drift out of alignment: every row shows the same position in both documents, and scrolling and expanding move both sides together by construction rather than by synchronisation. Added rows are green, removed rows red, modified rows amber, and each carries a +, − or ~ marker so the status does not depend on colour alone.

Everything it detects

Added keys, removed keys, modified values, type changes, array differences, object differences and nested differences at any depth. A key whose value is an entire object counts as one addition, not one per field inside it — the summary counts changes, not lines.

Comparison options

Compare by value, or by structure alone when only the shape matters. Ignore case in keys and string values, ignore leading, trailing and repeated whitespace, and ignore array order to match items by content instead of position. Formatting and key order are always ignored, because the comparison never sees the text.

Navigation and search

Step through the differences one at a time with previous and next; each jump opens whatever branches are needed and centres the result. Search runs across both documents at once and can be limited to keys or to values. “Only differences” hides every identical row; “Expand changed” opens precisely the branches that contain one.

JSON paths

Select any row to see its path in $.users[2].address.cityform, ready to copy, along with buttons to copy that row’s value from either side. Keys that are not valid identifiers are bracketed and quoted, so what you copy is a valid expression rather than an approximate one.

Summary and statistics

Added, removed, modified and total differences at a glance, alongside separate statistics for each document: characters, lines, objects, arrays, keys, maximum depth and size.

Export

Copy or download the full list of differences as a JSON report — every change with its path, its status and both values, plus the options the comparison ran under, so the result is reproducible.

Files, swapping and fullscreen

Upload a file into either side or drop one onto its panel; the filename becomes that side’s label. Swap the two documents with one press when you have loaded them the wrong way round, and go fullscreen when the comparison deserves the whole window.

1. 1. Both documents are parsed. Comparison operates on data, so both sides have to be valid JSON first. If either fails, the tool reports which side, what went wrong and exactly where, and waits — comparing against a document that could not be read would produce nonsense. For a document with several problems in it, the JSON validator lists them all in one pass.
2. 2. The two structures are walked together. Starting at the root, each value is matched with its counterpart. Objects are matched by key name, which is why property order is irrelevant. Arrays are matched by position, unless you have asked for them to be matched by content.
3. 3. Identical branches are skipped. When two subtrees are equal, the comparison records that and stops descending. This is what keeps large documents affordable: the parts that did not change cost one comparison each, not one per field.
4. 4. Each difference is classified. A key present on only one side is added or removed. A key on both whose values differ is modified, and if the two values are of different JSON types that is recorded as a type change. Containers themselves stay neutral — what changed is inside them.
5. 5. The results are rolled up.A final pass marks every branch that contains a difference, counts the additions, removals and modifications, and puts the changes in document order so that “next difference” walks the document the way you read it.

One consequence is worth knowing. Because objects are matched by name, renaming a key is reported as a removal plus an addition rather than as a rename — the comparison cannot know that city became town rather than one field being dropped and another added. The same is true of an array item moved a long way while also being edited.

The two terms get used interchangeably, but they describe different operations, and the difference shows up the moment a file gets reformatted.

A diff is textual. It is what git diff and every side-by-side merge tool does: compare two files line by line and report which lines were inserted, deleted or changed. It knows nothing about JSON. It would behave identically on a shopping list.

A compare is structural. Both documents are parsed and the resulting data is compared. It knows that objects are unordered, that whitespace between tokens is meaningless, and that 1 and "1" are different types.

Take one document written two ways:

1{"name":"Ada","id":1042}

1{2  "id": 1042,3  "name": "Ada"4}

A line diff reports every line as changed. A structural comparison reports nothing at all, which is the correct answer: no data changed. Now the reverse — a single edit inside a minified document:

1{"users":[{"id":1,"active":true},{"id":2,"active":true}]}

1{"users":[{"id":1,"active":true},{"id":2,"active":false}]}

A line diff says “line 1 changed”, which is true and useless. A structural comparison says $.users[1].active changed from true to false.

Neither is better in general; they answer different questions. Use a line-by-line text diff when the file itself is the artefact — when you care about the commit, the formatting or the line numbers. Use a structural comparison when the data is the artefact and the file is just how it happened to be written down.

A few patterns come up often enough to be worth naming, along with the settings that suit them.

Checking that a refactor changed nothing

Capture the output before and after, and compare with the default settings. The answer you want is zero differences. Anything else is a list of things to explain.

Reviewing an environment drift

Put two configuration files side by side and turn on “Only differences”. What remains is the entire delta between the environments, usually short enough to read in one screen.

Validating a schema change

Switch to compare by structure. Values are ignored and only the shape is examined, which answers “does this response still have the fields and types my client expects?” without the noise of different data.

Comparing unordered collections

Lists of tags, permissions or regions often carry no meaningful order. Turn on “Ignore array order” and items are matched by content, so a re-serialised list stops reporting a difference for every position that shifted.

Comparing data from inconsistent sources

When two systems disagree about capitalisation or padding, “Ignore case” and “Ignore whitespace” strip that layer away so the differences that remain are differences of substance.

Attaching evidence to a bug report

Download the differences. The report lists every change with its path and both values, along with the options used, so whoever reads it can reproduce exactly the comparison you ran. If the ticket wants something that reads like a code review, the JSON diffruns the same comparison and prints it in Git’s unified format instead.