JSON Diff is a browser-based tool that compares two strict JSON documents as parsed data structures rather than as raw text, producing a deterministic list of added, removed, changed, and type-changed entries at RFC 6901 JSON Pointer paths. Unlike a line-based text diff, it ignores whitespace, indentation, and object member order so that real value, type, key, and positional array changes remain visible without being drowned in formatting noise. The output is a concise, copy-ready change list with before and after values at every affected path, ready for code review, ticket comments, or manual reconciliation. Because both sides are parsed under RFC 8259, comments, trailing commas, undefined values, NaN, Infinity, BigInt literals, and JavaScript object syntax are rejected before comparison begins. Each input can be any JSON value — object, array, string, number, Boolean, or null — and the comparison runs locally in the browser so the documents never leave your machine. That combination of strict parsing, structural comparison, and local processing is what makes the tool a reliable way to find the difference between two JSON files.
What JSON Diff Actually Compares
JSON Diff takes two strict JSON documents, parses them into native data structures, and then walks both trees side by side. At every location it classifies the relationship between the left value and the right value into one of four buckets: added, removed, changed, or type-changed. The location itself is recorded as an RFC 6901 JSON Pointer, the same path syntax used by JSON Patch and many API contracts, so the result reads naturally to anyone already working with JSON-based protocols.
Objects are compared by their own member names rather than by source-text order, and keys are sorted before reporting so the output is stable across runs. Arrays are compared positionally using zero-based indices, which means a reorder produces a real, visible change rather than a silent rename. Primitives are checked both for type and value: a number becoming a string is a type-changed entry, two strings that differ in any character are a changed entry, and positive and negative zero are treated as the same numeric value.
Every difference is reported with the values that produced it. Added entries include the right-hand value, removed entries include the left-hand value, and changed entries include both. When a whole subtree moves, changes type, or disappears, the full nested object or array appears as the value rather than being summarized away, so reviewers can see exactly what is at stake.
Why Structural Diff Beats Text Diff
A line-based text diff treats JSON as if it were free-form prose. Reformat one object from two-space indentation to four-space, reorder members alphabetically, or save the file through a pretty-printer, and a text diff lights up with dozens of phantom changes. Reviewers waste time deciding whether the meaningful edit is buried inside the formatting churn or whether the diff is entirely cosmetic.
JSON Diff skips all of that by parsing both inputs first. After parsing, whitespace is irrelevant and object member order does not exist as a property, so the only entries that appear in the change list correspond to real differences in keys, values, types, or array positions. The practical effect is a much shorter, much more trustworthy review surface.
| Aspect | Text Diff | JSON Diff |
|---|---|---|
| Input treated as | Raw characters | Parsed JSON structure |
| Whitespace and indentation | Counts as differences | Ignored |
| Object key order | Counts as differences | Ignored |
| Array comparison | By line position | By zero-based index |
| Output format | Inline additions and removals | Structured change list at JSON Pointer paths |
| Detects type changes | No | Yes, as a separate category |
| Reports exact locations | By line and column | By RFC 6901 JSON Pointer |
The comparison runs locally in the browser, so the documents never leave your machine. There is no upload, no server round trip, and no third-party processor handling your data. For configuration files, API responses, or any JSON that may contain secrets or personal information, that local processing model is a practical safeguard in addition to a technical detail.
How to Compare Two JSON Documents
Use the JSON Diff tool whenever you have two JSON documents and need a clean, deterministic list of what is actually different between them. The following steps walk through the entire workflow from preparing the inputs to acting on the output.
- Prepare two strict JSON documents. Both inputs must parse under RFC 8259, so strip any comments, trailing commas, undefined values, NaN, Infinity, BigInt literals, or JavaScript object syntax before pasting. Run each side through the JSON Validator or JSON Formatter if you are unsure it will parse cleanly.
- Paste the older or left-hand document into the left input and the newer or right-hand document into the right input. Formatting and indentation do not need to match; only the parsed structure is compared, so a minified left and a pretty-printed right are perfectly fine.
- Run the comparison. JSON Diff parses both sides, walks them recursively, and produces a deterministic list of differences. Keys are sorted for stable reporting, so re-running the same comparison on the same input always produces the same output.
- Inspect each entry in the change list. For every added, removed, changed, or type-changed entry, read the RFC 6901 JSON Pointer path, the kind of change, and the before and after values. A primitive with the same JSON type but a different value is changed, while a primitive that switched type — for example, a number becoming a string or null becoming an object — is reported as type-changed.
- Copy the change list for review. The structured output is suitable for code review comments, ticket updates, or change logs. Review sensitive before and after values before pasting the list anywhere that gets logged or indexed.
- Apply changes through a dedicated patch implementation with application-specific tests when the change list needs to be acted on automatically. Treat the JSON Diff result as authoritative evidence of where the two documents differ, not as an executable plan, because the output is not RFC 6902 JSON Patch.
The root of the document is the empty JSON Pointer, displayed as root in the human-readable list when the entire value changes. Slashes inside object member names are escaped as ~1 and tildes as ~0 so that paths always remain valid RFC 6901 references even when keys contain reserved characters. Array positions use decimal index tokens, so the third element of an array at the root appears as /2 rather than as a name.
Reading the Change List
Every entry in the output identifies one location and one kind of difference. The path tells you where the difference lives, and the included values tell you what produced it. Getting fluent with the path syntax is the fastest way to skim a long change list, because a single JSON Pointer points at exactly one node in the parsed structure regardless of how deeply nested it is.
| Entry kind | What it means | Values shown |
|---|---|---|
| added | Key or array position exists on the right but not on the left | Right value |
| removed | Key or array position exists on the left but not on the right | Left value |
| changed | Same key or index, same JSON type, different value | Left and right values |
| type-changed | Same key or index, different JSON type | Left and right values with type tags |
Because object keys are sorted before reporting, two runs on the same input always list child differences in the same order. Array entries are reported by their zero-based index, which makes it easy to scan for shifts caused by insertions or deletions at the front of a list. If a value moves from one index to another, the result contains a removal, an addition, or multiple changed entries rather than a single semantic move, because the tool does not guess identity keys, compute longest-common-subsequence alignments, or treat arrays as sets.
Limits, Edge Cases, and Gotchas
JSON Diff enforces concrete limits and fails rather than silently truncating a larger result. Each input is capped at 500,000 characters, comparison nesting is capped at 50 levels, and the change list is capped at 5,000 entries. Inputs that exceed those bounds are rejected up front so the output stays reviewable rather than becoming a partial, misleading summary.
Numbers are parsed as JavaScript Numbers, which means very large integers and high-precision decimals can already be rounded before the comparison begins. Positive and negative zero compare as the same JSON numeric value, so 0 and -0 do not appear as a difference. If exact decimal spelling, arbitrary-precision numbers, or duplicate member names inside a JSON object matter to your contract, compare the source with a parser and numeric model designed for that case instead of relying on this browser-based comparison.
Duplicate keys in JSON text are a special case. Standard JSON parsing resolves them before the comparison tool receives the object, so two members with the same name cannot be compared as separate entries. If your data format permits duplicate keys, normalize it to strict JSON before diffing. Trailing comments, block comments, single-quoted strings, and other non-strict JSON constructs are rejected by the strict RFC 8259 parser and surface as a parse error rather than a silent skip.
Review sensitive values before copying the change list into logs, tickets, or chat. The output includes the full before and after values at every affected path, which is exactly what a reviewer needs but also exactly what a secret-scanner does not want to see written down twice.
When JSON Diff Is Not the Right Tool
JSON Diff is a comparison tool, not a transformation tool. Its output is a product-defined change list with before and after values, not RFC 6902 JSON Patch, JSON Merge Patch, a unified text diff, or a schema migration. It does not emit move, copy, or test operations, and it does not claim that a removed value can be restored after surrounding changes.
If your workflow needs to apply changes automatically to a live document, run the change list through a maintained patch library and back it with application-specific tests. If your data format allows comment-style annotations, trailing commas, or other non-strict JSON, normalize it first with the JSON Formatter or the JSON Validator. If you need to compare two files in a more general sense — not as JSON structures — a line-based Diff Checker is the more direct choice.
For related work that often sits alongside a JSON comparison, the JSON Formatter can normalize indentation before pasting, and a general Linux file diff workflow covers the broader case of comparing arbitrary text files. When the goal is specifically to find the structural difference between two JSON documents, JSON Diff is the focused, deterministic option.
Related reading: Format JSON Files in Notepad++: Plugins and Alternatives.