How to compare JSON — two steps

Paste the first JSON into the left panel and the second JSON into the right panel. Both must be valid JSON — if either panel has a parse error, it is highlighted in red before the diff runs.
Read the diff report. The tool walks both trees and outputs three categorized lists: Added paths (exist in B, not A), Removed paths (exist in A, not B), and Changed paths (exist in both but with different values). Unchanged paths are not shown — the output only surfaces what actually differs.

Each path in the report uses dot notation for object keys (user.profile.email) and bracket notation for array indices (items[3].price). You can immediately locate the differing node in either input panel by navigating to that path.

Why structural diff, not string diff?

A text diff tool — like git diff or a side-by-side text comparison — compares bytes. For JSON, this produces false positives on every reformatting: a document pretty-printed with 2-space indent looks completely different from the same document with 4-space indent, even though they represent identical data. Key ordering is even worse: {"a":1,"b":2} and {"b":2,"a":1} are the same JSON object, but a text diff marks every line as changed.

A structural diff parses both documents into in-memory trees first, then compares the trees. Key order within objects is ignored — the diff engine sorts keys before comparing. Whitespace and formatting differences disappear entirely. Only semantic differences — a value that changed, a key that was added or removed — appear in the output.

This matters in practice every time you compare an API response captured last week against one captured today, or a config file before and after a deployment. Text diff would flag every reformatting change. Structural diff shows you only what actually changed.

How differences are classified

Added — the path exists in the right-hand document (B) but not in the left-hand document (A). Something was added between the two versions.
Removed — the path exists in A but not in B. Something was deleted.
Changed — the path exists in both A and B, but the values differ. The report shows both the old and new value at each changed path, making it easy to see what it was and what it became.
Unchanged — identical in both. Not reported, to keep the output focused on what matters.

Type changes are reported as Changed. If a field was "count": "5" (string) in A and "count": 5 (number) in B, that appears as a Changed path — because the values are not strictly equal even though they look similar. This is intentional: strict equality is what JSON serializers and deserializers use.

Structural diff vs text diff — when to use each

Scenario	Use structural diff	Use text diff
API response changed between deploys	Yes	No — key order may differ
Config file, same formatter both times	Yes	Acceptable
Checking if reformatting changed content	Yes	No — always shows changes
Git commit review of JSON file	Yes	Works if normalized
Non-JSON text (YAML, TOML, ini)	No	Yes
Comparing JSON comments (JSON5)	No — convert first	Yes

Array diff strategy: index-by-index

Arrays are compared position-by-position. Element 0 in A is compared to element 0 in B, element 1 to element 1, and so on. If one array is longer, the extra elements are reported as Added or Removed.

This is the correct strategy for the primary use cases of this tool: comparing API responses where array order is meaningful (a paginated list of results), and comparing config arrays where each index has a defined role.

An alternative is LCS (Longest Common Subsequence) or Myers diff — the algorithm used by git diff. LCS tries to detect items that shifted position and classify them as "moved" rather than "removed from index 2, added at index 5." LCS is computationally heavier (O(n²) worst case) and produces longer, harder-to-read output for config/API comparison. Index-wise diff is O(n) and produces clean output for the common case.

If you need to detect moved items in large JSON arrays — for example, comparing two sorted datasets where elements shuffled — the right tool is jq with custom sorting or a purpose-built LCS differ. For API and config comparison, index-by-index is what you need.

JSON Patch (RFC 6902) vs JSON Diff — different purposes

JSON Patch (RFC 6902) is a machine-applicable operation list:

[
  { "op": "replace", "path": "/user/email", "value": "new@example.com" },
  { "op": "add", "path": "/user/phone", "value": "+1-555-0100" }
]

A JSON Patch document tells a system exactly what to do to transform document A into document B. It is designed to be sent over a network (PATCH request), stored in a database, or applied by a library like fast-json-patch.

This tool produces a human-readable diff — a list of what changed, designed for a developer to read and understand, not for a machine to apply. The two formats serve different workflows. Generating RFC 6902 patch output from the diff is on the roadmap.

Practical use cases

API response comparison. Capture a response before and after a backend change. Paste both here to confirm only the expected fields changed — and nothing unexpected regressed.
Config auditing. Compare a production config against a staging config to find undocumented differences before a deployment.
Test assertion review. When a snapshot test fails, paste the expected and actual JSON here to see exactly which fields diverged instead of reading a raw text diff.
Before/after migration check. After migrating a database record or transforming a data model, confirm that the transformation produced the expected structure.
Third-party API versioning. When a third-party API releases a new version, compare a v1 response against a v2 response with real data to understand exactly what the schema change involved.
Feature flag audit. Compare a feature flag config before and after a change to verify the right flags were toggled.

Handling large JSON documents

The diff algorithm is O(n) in the number of leaf nodes across both documents. Memory usage scales with the size of both parsed trees. In practice:

Documents up to a few megabytes each compare instantly.
Documents in the 5–20 MB range may take a second or two to parse and diff.
Documents above ~50 MB may exhaust browser memory — the tab will become unresponsive.

For very large JSON comparison, the command-line tool jq is the right choice. The pattern jq --sort-keys . a.json > a_sorted.json && jq --sort-keys . b.json > b_sorted.json && diff a_sorted.json b_sorted.json normalizes key order and produces a text diff that is meaningful for large files without loading everything into browser memory.

FAQ

Can I diff YAML or JSON5 directly?

Not directly — this tool requires valid JSON on both sides. Convert YAML to JSON first using the YAML ↔ JSON converter. For JSON5, strip comments manually or use a JSON5-to-JSON converter before pasting here.

How large a document can it handle?

Comfortably up to a few megabytes per side. The diff is O(n) in node count and runs entirely in the browser. For documents larger than ~50 MB, use jq --sort-keys to normalize both files, then diff them on the command line.

Is my data private?

Yes. Both JSON inputs are parsed and diffed entirely in your browser using JavaScript. No data is sent to any server. The tool works completely offline once the page is loaded.

Related tools

JSON Formatter — Format, validate, and beautify JSON online. 100% client-side — your data never leaves your browser.
XML Formatter — Format, validate, and beautify XML documents.
YAML ↔ JSON Converter — Convert between YAML and JSON formats with full fidelity.
CSV to JSON Converter — Convert CSV files to JSON with proper quoting and escaping.

Pillar

Part of Data & Format — JSON, YAML, XML, CSV, SQL, Markdown.

Written by Mian Ali Khalid. Last updated 2026-05-13.

Compare JSON