Skip to content
LocalOnly

JSON Compare & Diff

Stable

Compare two JSON documents and see a precise structural diff.

Everything is processed locally in your browser

About JSON Compare & Diff

The JSON Compare tool lets you compare two JSON documents online and get a structural, semantic diff rather than a naive text comparison. This JSON comparator ignores key order and whitespace and instead reports exactly which properties were added, removed, or changed, and where. That makes it ideal for spotting the real differences between two JSON files, API responses, config versions, or fixtures.

Features

  • Semantic comparison that ignores key order and formatting
  • Clearly labels added, removed, and changed values
  • Reports the full path to each difference, including array indices
  • Distinguishes a type change from a value change
  • Optional key sorting and normalization before comparing
  • Handles deeply nested objects and large arrays

How to use JSON Compare & Diff

  1. 1

    Paste the original JSON

    Add the first document into the left side as your baseline.

  2. 2

    Paste the updated JSON

    Add the second document into the right side to compare against.

  3. 3

    Review the diff

    See every added, removed, and changed value with its exact path.

  4. 4

    Act on the changes

    Use the structured diff to confirm expected updates or catch regressions.

Examples

Diff between two versions

One value changed and one key was added.

Input

// A
{ "name": "Ada", "plan": "free" }

// B
{ "name": "Ada", "plan": "pro", "seats": 3 }

Output

~ plan: "free" -> "pro"
+ seats: 3

How JSON diffing works

Why a text diff is the wrong tool for JSON

A line-based diff compares sequences of characters. It has no idea that `{"a":1,"b":2}` and `{"b":2,"a":1}` are the same value, so it reports two changed lines where nothing changed. Reformat a file and every line differs. Reindent it and the whole document is a change.

A structural diff parses both documents first and then compares the resulting values. Objects are matched by key, so ordering is irrelevant. Whitespace is gone before the comparison starts. Numbers are compared by value, so `1.0` and `1` are equal. What you get back is a list of semantic differences: keys added, keys removed, values changed.

That difference in approach is why a structural comparison of two API responses is usually a handful of lines while a text diff of the same pair can be hundreds.

Arrays are where diffing gets genuinely difficult

Objects match by key, which is unambiguous. Arrays have no keys, so a differ has to guess at correspondence - and there is no universally correct answer. If an element is inserted at the front of a 100-element array, comparing by index reports 100 changes, when the honest description is one insertion.

The two available strategies both have costs. Index-based comparison is fast and predictable but reports insertions and deletions as long runs of modifications. Similarity-based matching tries to pair elements by content and produces far more intuitive results, but it is slower and can mis-pair genuinely similar objects.

The practical implication is about how you read the output. When an array diff looks unreasonably large, check whether something was inserted or removed near the start. That single edit is often the entire cause of what looks like wholesale change.

Reading a diff, and reducing the noise before you start

Differences come in three kinds and it is worth separating them mentally. An addition is a path present in the second document only. A removal is a path present in the first only. A modification is a path in both with different values. Type changes - a field that went from a number to a string - are worth particular attention, because they are the ones most likely to break a consumer at runtime.

Two preparation steps make diffs dramatically more readable. Sorting keys in both documents removes any residual ordering artefacts. Removing nulls or empty values from both cuts out placeholder fields that differ without meaning anything. Do both when comparing responses from two different environments, where incidental differences tend to swamp the real ones.

Which tool should you use?

These tasks overlap. Here is how to pick the right one for what you are actually doing.

You are comparing two API responses or config files
This tool. Key-based matching means ordering and formatting differences never appear.
You want to combine two documents rather than contrast them
The JSON Merge tool applies one document on top of another.
The two documents differ only in key order
A structural comparison will correctly report no differences. If you need the files themselves to match byte for byte, sort both with the JSON Sort Keys tool.
You need to know why one document is much larger than the other
The JSON Statistics tool answers that faster, by reporting depth, key counts and type distribution.

Use cases

  • Confirming what changed between two versions of an API response
  • Diffing config files across environments like staging and production
  • Verifying that a data migration only altered the intended fields
  • Comparing a test fixture against actual output to debug failures
  • Reviewing changes in a JSON document without noisy formatting diffs

Troubleshooting common errors

An array shows dozens of changes after a single insertion

Why: Index-based comparison shifted every subsequent element by one position, so each index now holds a different value.

Fix: Read it as one insertion. If the arrays hold objects with stable identifiers, comparing them keyed by that identifier is far more informative.

Two documents you believe are identical report differences

Why: Usually number formatting or invisible characters - trailing whitespace inside a string value, or a byte order mark.

Fix: Minify both and compare the results. That eliminates every formatting variable and leaves only real differences.

The diff is too large to be useful

Why: Incidental differences - null placeholders, key ordering, timestamps - are drowning the meaningful ones.

Fix: Sort keys and strip empty values from both documents first, then compare again.

A change is reported for a field that looks the same

Why: A type change: `"42"` and `42` display almost identically but are a string and a number.

Fix: Check the types. These are the differences most likely to break a strict consumer, so they are worth surfacing rather than hiding.

Limitations

What this tool deliberately does not do, so you know when to reach for something else.

  • Array comparison cannot know which elements correspond, so insertions and deletions can be reported as long runs of modifications.
  • Key order differences are correctly ignored, which means this tool cannot verify that two files are byte-identical.
  • Duplicate keys collapse during parsing and so are never reported as differences.
  • Very large documents are limited by browser memory, since both must be parsed and held at once.
  • There is no notion of which document is authoritative - the comparison is symmetric.

Frequently asked questions

Learn more

Command Palette

Search for a tool or command