JSON Diff Viewer | DevTools by Infinfy

Why JSON-aware diffing matters

Consider two API responses that are semantically identical — same data, same structure — but formatted differently. Maybe one was pretty-printed with 4-space indentation, the other with 2-space. Maybe one server serializes object keys in alphabetical order, the other preserves insertion order. Maybe the responses were captured on different days and a timestamp field changed by one second.

A plain text diff on these two documents would report every line as changed, even though the actual data is identical. This is useless at best and misleading at worst — you waste time investigating phantom differences, and real structural changes (a missing field, a changed value type, an array that lost an element) get buried in the noise.

A JSON-aware diff solves this by normalizing both documents before comparing them. This tool parses both inputs, validates that they are well-formed JSON, then re-serializes both with identical 2-space indentation. The diff then runs on these normalized forms, so the only differences that appear are genuine structural ones.

JSON diff for API regression testing

API regression testing is the practice of verifying that a code change did not alter the external behavior of your API. The simplest and most reliable form is response snapshotting: save a known-good API response, make your code change, call the same endpoint again, and diff the new response against the saved one. A clean diff means your change was safe.

Here is a minimal shell workflow for JSON API regression testing:

# Step 1: capture the golden response (before your change)
curl -s -H "Authorization: Bearer $TOKEN" \
  https://api.example.com/v2/users/42 | jq -S . > snapshots/users_42.json

# Step 2: make your code change and redeploy to staging

# Step 3: capture the new response
curl -s -H "Authorization: Bearer $TOKEN" \
  https://staging-api.example.com/v2/users/42 | jq -S . > snapshots/users_42_new.json

# Step 4: compare — zero output means no differences
diff snapshots/users_42.json snapshots/users_42_new.json

The jq -S . flag sorts all object keys alphabetically. This is important for reliable regression testing: without it, two identical responses with different key orders would produce a false positive diff. Always normalize before snapshotting.

For teams that need this as a structured test suite with CI integration, environment management, and assertion syntax, Postman provides a full API testing platform. Tests can be written in Postman's JavaScript sandbox, run against multiple environments (dev, staging, prod), and triggered from CI/CD pipelines. Postman also supports mock servers, which let you test API consumers against a fixed contract without a live backend. For production error monitoring when something does slip through, Sentry captures exceptions with full context — request parameters, user identity, and stack traces — and groups them intelligently to reduce alert fatigue.

Comparing JSON config files

Modern applications often use JSON for configuration — package.json, tsconfig.json, .eslintrc.json, Terraform outputs, CloudFormation templates. When environments diverge — "why does this work in dev but not in prod?" — comparing the JSON configs between environments is often the fastest path to the answer.

Common scenarios where this diff tool is useful:

package.json version drift — compare your local package.json against a colleague's to find dependency version mismatches that explain why the build passes for one developer and fails for another.
Terraform plan output — paste the JSON output of terraform show -json before and after a plan to inspect exactly which resource attributes will change.
Environment variable configs — compare the JSON export of secrets from dev vs. staging to find missing or mismatched values.
Feature flag payloads — compare the JSON payload from your feature flag service between environments to diagnose why a feature behaves differently.

How normalization works in this tool

When you paste JSON into either panel, this tool first calls JSON.parse() on the input. If the parse fails, an error message appears showing the exact location of the syntax error. If the parse succeeds, the parsed JavaScript object is immediately re-serialized with JSON.stringify(parsed, null, 2).

This two-step process guarantees that both sides of the diff have identical formatting: 2-space indentation, the same newline style, the same quoting style for strings. The diff then runs on the normalized strings. Any difference in the output is a semantic difference in the data, not a formatting artifact.

The key ordering problem

One limitation of this tool's normalization approach: it preserves the original key order from each document. If Document A has {"name": "Alex", "role": "admin"} and Document B has {"role": "admin", "name": "Alex"}, the diff will report both lines as changed even though the data is semantically identical.

This is a deliberate choice. In many JSON APIs, key order is meaningful — OpenAPI specs, JSON Schema definitions, and configuration files often rely on key ordering for readability or processing. Silently reordering keys would change what you are looking at. If you want key-sorted comparison, pre-process your JSON with jq -S . before pasting.

Diffing deeply nested JSON

When a deeply nested value changes — say a field five levels deep in a JSON tree — the normalized diff will show several lines of context around it (the opening braces and keys that lead to it) as unchanged, then the specific value line highlighted in red/green. The line numbers help you navigate to the right section.

For deeply nested documents where you want to understand the full path to a changed value, use the JSON Tree Viewer to explore the structure first, then use this diff tool to compare versions.

Command-line JSON diff

For automated diffing in scripts and CI:

# Normalize and diff with jq + diff
diff <(jq -S . a.json) <(jq -S . b.json)

# Use git diff for colorized output outside a repo
git diff --no-index <(jq -S . a.json) <(jq -S . b.json)

# Use jd (JSON diff CLI) for semantic JSON diffing
# Install: go install github.com/josephburnett/jd@latest
jd a.json b.json

# jd with patch format (can be applied back)
jd -p a.json b.json > patch.jd
jd -p -f patch.jd a.json  # applies patch to reconstruct b.json

jd (JSON diff) is a purpose-built CLI that understands JSON semantics: it treats objects as unordered sets of key-value pairs, so key order differences are not reported as changes. For regression testing where key order is irrelevant, jd produces cleaner output than diff + jq -S.

Frequently Asked Questions

Why should I use a JSON diff tool instead of a plain text diff?

A plain text diff compares characters as-is. If two JSON responses are semantically identical but formatted differently — different indentation, different key order, line breaks in different places — a plain text diff will report hundreds of false differences. A JSON-aware diff normalizes both documents first: it parses, then re-serializes both with the same indentation and key ordering before diffing. The result shows structural changes only, not formatting noise.

Does this tool normalize key order?

This tool re-formats both JSON documents with consistent 2-space indentation using JSON.stringify before diffing. It does not sort keys alphabetically, because key order is semantically meaningful in some JSON APIs and changing it would alter the structure being compared. If you need key-sorted comparison, pre-process your JSON with jq -S . before pasting.

How do I diff two API responses for regression testing?

Save your known-good response: curl -s https://api.example.com/endpoint | jq . > golden.json. After your change, curl the same endpoint again and paste both into this tool. A clean diff (no colored rows) means your change did not alter the API response structure. For automated regression testing in CI pipelines, use Postman collection runner or write assertions directly against parsed response objects.

What is the maximum JSON size this tool handles?

The tool handles JSON documents that expand to up to 2,500 lines when formatted. Very large JSON payloads (hundreds of kilobytes) may be slow in the browser. For large file diffing, use jq to format both files (jq . a.json > a_formatted.json && jq . b.json > b_formatted.json) and then diff them in the terminal with diff a_formatted.json b_formatted.json.

What does it mean when only whitespace or comma position changed?

This tool re-parses and re-formats both documents with identical formatting before diffing, so cosmetic whitespace differences are eliminated. If the diff shows a change, it is a genuine structural change — a value, key, array item, or nesting level is different. A change in comma position cannot appear because the tool re-serializes both from the parsed object model.