{{ summary.primary }}
{{ summary.detail }}
{{ badge.label }}
JSON diff inputs
Choose the review lens before comparing so array matching and type strictness are intentional.
Paste the baseline response, export, fixture, or configuration snapshot.
{{ sourceStatus || 'Drop JSON or TXT onto the original editor.' }}
Paste the candidate response, export, fixture, or updated configuration.
{{ revisedStatus || 'Drop JSON or TXT onto the revised editor.' }}
Use the sample for a cold start, then swap or normalize the two sides without leaving the page.
JSON pair
The structural diff updates after each edit.
Use change rows for review, all rows for audits, or summary rows for a compact handoff.
Position mode is patch-friendly; key mode is useful for API arrays whose item order may change.
Use a stable identifier such as id, sku, name, key, or code.
Keep strict for contract checks; use coercion only when transport formatting is expected to differ.
Use this for volatile timestamps, request IDs, cache keys, or fields intentionally outside review.
Compact keeps ledgers readable; expanded is better for short fixture diffs.
Turn on for audit trails that need object and array branch evidence.
{{ includeContainers ? 'On' : 'Off' }}
{{ reportText }}
Path Status Original Revised Note Copy
{{ row.Path }} {{ row.Status }} {{ row.Original }} {{ row.Revised }} {{ row.Note }}
Operation Path Original Revised Copy
{{ row.Operation }} {{ row.Path }} {{ row.Original }} {{ row.Revised }}
{{ jsonText }}
Customize
Advanced
:

Introduction:

JSON review is rarely about the number of text lines that changed. A payload can be minified, pretty-printed, or reordered by a serializer while carrying the same parsed data, and a one-character value change can still break an API contract, configuration rollout, migration check, or test fixture.

Structural comparison starts after the text is parsed. Objects, arrays, strings, numbers, booleans, and null values are walked by path, so the review can focus on which value was added, removed, changed, or converted to another JSON type. That is a different question from whether two files look identical in a line diff.

Path
A location such as $.order.status or /order/status that points to one value inside a JSON document.
Value type
The JSON category at a path, such as string, number, object, array, boolean, or null.
Array meaning
The rule that decides whether array position matters or whether items should be matched by a stable value such as an ID.
JSON text parsed into paths and compared as review rows.

Different reviews need different matching rules. API regression checks usually care about missing fields, changed types, and stable record identifiers. Configuration drift checks often need to suppress timestamps, request IDs, generated cache keys, and other intentional noise. Fixture updates may need to decide whether an array reorder is meaningful behavior or only a change in output order.

Structural diffing also has boundaries. A changed path does not prove the revised value violates a business rule, and a clean structural comparison does not prove the raw source texts are byte-for-byte identical. Duplicate object names, numeric strings, ignored path prefixes, and array matching policies can all change the evidence a reviewer sees.

The safest review starts by naming the purpose: strict patch evidence, migration audit, configuration drift, or unordered list comparison. The same two JSON documents can produce a different path ledger when that purpose changes, and that is useful only when the rule is deliberate.

How to Use This Tool:

Choose the comparison profile first, then confirm the matching notes before treating the changed-path count as evidence.

  1. Set Comparison profile to API regression, Config drift, Migration audit, or Strict patch review. The profile fills in starting choices for array matching, ledger scope, and type handling.
  2. Paste the baseline document into Original JSON and the candidate document into Revised JSON. You can also drop text into either editor or browse for a .json or .txt file under 4 MB.
  3. Use Load sample when you want a known comparison before adding private data. Use Swap if the baseline and revised documents were entered in the wrong editors.
  4. Run Format or Format both when the JSON is hard to read. If parsing fails, an Input issue alert names the editor and usually points near the line and column that stopped the comparison.
  5. Choose Array matching. Position matching fits ordered arrays and patch-style review, primitive sorting helps with unordered scalar lists, and object-key matching fits item arrays with a stable Array object key such as id, sku, or code.
  6. Open Advanced for review rules that change interpretation. Type policy decides whether numeric strings may match JSON numbers. Ignore paths accepts dot paths or JSON Pointer paths, and a trailing * ignores every path with that prefix.
  7. Read Diff Report first, then inspect Path Ledger, Patch Ops, Change Mix Chart, or JSON when you need a table, patch-style rows, a count chart, or structured evidence. If the report says captured rows were capped, narrow the JSON to the object or array under review.

Before copying or downloading evidence, confirm that the summary line, array policy badge, ignored-path count, and review notes match the review you intended to run.

Interpreting Results:

Changed paths is the main triage number. It counts added paths, removed paths, changed primitive values, and type changes after the active ignore, type, and array rules have been applied. No differences means no counted structural differences remain under those rules; it does not mean the raw texts share the same spacing, object member order, or original bytes.

  • Added means a path exists only in Revised JSON.
  • Removed means a path exists only in Original JSON.
  • Changed means both paths exist with the same JSON type but different primitive values or changed container evidence.
  • Type changed means the same path moved between JSON types, such as string to number or object to array.
  • Ignored means the path matched the ignore list and should not be counted as reviewed.

False confidence usually comes from ignored paths, numeric-string coercion, or object-key array matching. Check Diff Report notes when object-key matching falls back to position matching because an item is missing the key or because key values are duplicated. Switch Ledger rows to All traversed paths when unchanged or coerced matches need to be visible in the review record.

Use Patch Ops as review evidence, not as a guaranteed JSON Patch document. The rows show add, remove, and replace-style changes with paths and values, but they do not infer move, copy, or test operations, and object-key paths may need conversion before use in another patch system.

Technical Details:

A JSON document serializes one value. That value can be an object, array, string, number, boolean, or null. Whitespace around structural characters is insignificant after parsing, so reindentation and line wrapping should not create structural differences.

Objects and arrays need different comparison rules. Object members are name-value pairs, and member order is not a dependable meaning signal for interchange. Array order can be meaningful, so position matching is the strict default for patch-style evidence unless the review deliberately treats scalar arrays as multisets or object arrays as records keyed by a stable field.

Object member names should be unique for predictable interchange. When duplicate names appear, different parsers may keep one value, reject the object, or expose the duplicates differently. A duplicate-name note should be treated as a warning that the parsed structural view may not reveal every authoring mistake in the original text.

Transformation Core:

JSON structural comparison stages
Stage Rule Evidence Produced
Parse Each editor must contain one valid JSON value. Empty input or invalid syntax stops the comparison. Input issue alert with parser detail when available
Walk paths Objects are visited by member name, arrays follow the selected array policy, and primitive values are compared at matching paths. Total rows, path statuses, and type notes
Apply ignore rules Exact dot paths and JSON Pointer paths are skipped, while a trailing * skips matching path prefixes. Ignored rows and ignored-path count
Summarize evidence Material differences are counted, capped row evidence is prepared, and count data is grouped for the chart. Diff Report, Path Ledger, Patch Ops, Change Mix Chart, and JSON

Count Rule:

The headline count includes only statuses that represent material differences after the active comparison rules.

ChangedPaths = Added + Removed + Changed + TypeChanged

Ignored and Unchanged rows are excluded from Changed paths. In Differences only mode, unchanged rows may be absent from the ledger because they are not needed for a compact review.

Array matching policies and review effects
Array Policy Comparison Rule Use When
Compare arrays by position Index 0 compares with index 0, index 1 with index 1, and the longer array produces added or removed paths. The array is ordered, or the evidence is meant to resemble a strict patch review.
Sort primitive arrays Primitive values are counted by stable value, so order-only changes in strings, numbers, booleans, and null values can disappear. The array represents tags, flags, scopes, or another unordered scalar list.
Match object arrays by key Objects are matched by the selected member value when every item has that member and key values are not duplicated. The array contains records with stable identifiers, such as item IDs, SKUs, names, keys, or codes.
Fallback to position If a requested key is missing or duplicated, the comparison returns to index matching and records a review note. Use the note to choose a better key or accept position matching deliberately.
JSON path notation and patch evidence
Notation Meaning Caution
Dot path A readable location such as $.order.status or $.items[0].sku. Useful for review notes and human discussion.
JSON Pointer A slash path such as /order/status; ~ and / are escaped inside reference tokens. Useful for standards-based path exchange when paths use ordinary object names and array indexes.
Patch-style operation add, remove, and replace rows describe how compared paths differ. They are evidence rows, not a complete JSON Patch sequence with move, copy, or test operations.

For fair repeat comparisons, keep the profile, array policy, object key, type policy, ignore paths, and container-row setting the same. Large comparisons retain summary counts while table artifacts capture a bounded row set, so a capped-row warning means the source JSON should be narrowed before detailed evidence is trusted.

Privacy Notes:

After the page assets load, parsing, local file reading, structural comparison, chart rendering, copying, and downloads run in the browser tab. Pasted JSON and supported file contents are not uploaded by the comparison workflow.

  • Review secrets, tokens, customer records, and unreleased payloads with care. Browser history, screenshots, clipboard contents, downloaded files, and shared links can still expose sensitive values.
  • The current inputs can be represented in the page address for restoration and sharing. Remove sensitive values before copying a link.
  • File selection and drag-and-drop accept JSON or text files under 4 MB for each editor.

Worked Examples:

Order API regression. The sample compares an order that changes $.order.status from "pending" to "paid", updates item sku=A1, adds item sku=C3, changes the customer tier, adds a coupon, and ignores $.order.meta.request_id. With object-key matching on sku, the summary reports 7 changed paths, 8 path rows, and 1 ignored path.

Fixture reorder. Comparing [{"id":1,"v":"a"},{"id":2,"v":"b"}] with [{"id":2,"v":"b"},{"id":1,"v":"a"}] under position matching produces four changed primitive paths because both indexes now hold different values. With object-key matching on id, the same pair reports No differences because the records still match by identifier.

String-to-number migration. Comparing {"count":"42"} with {"count":42} under Strict JSON types gives a Type changed row at $.count. Under Coerce numeric strings, the pair can disappear from Differences only because the numeric value matches after coercion. Use All traversed paths when that matched value needs to appear in the ledger.

Bad input during review. If Original JSON contains {"id":42,}, the comparison stops with an Input issue parse message instead of producing misleading rows. Remove the trailing comma, use Format to confirm the value parses, then read Diff Report again.

FAQ:

Why does formatting not count as a difference?

Both inputs are parsed as JSON values before paths are compared. Whitespace, indentation, and line wrapping are not part of the parsed value.

Why did an array reorder create many changed paths?

Compare arrays by position treats each index as meaningful. If order is not meaningful and every object has a stable identifier, use Match object arrays by key and set Array object key.

Are Patch Ops a valid JSON Patch file?

No. Patch Ops gives add, remove, and replace-style evidence rows for review. It does not build a complete JSON Patch document with move, copy, or test operations.

Why do values that look different show no differences?

Check Ignore paths, Type policy, and Array matching. Ignored paths are skipped, numeric coercion can treat "42" and 42 as equal, and object-key matching can remove order-only array changes.

Does pasted JSON leave the browser?

The comparison workflow runs in the browser after the page assets load. Do not share the page URL, screenshots, exports, or clipboard contents until sensitive values have been removed.

Glossary:

JSON value
One parsed JSON object, array, string, number, boolean, or null.
Structural comparison
A review of parsed JSON paths and values rather than raw text lines.
Path
A location inside a JSON value, shown as a dot path or JSON Pointer.
JSON Pointer
A slash-separated path syntax for identifying a value inside a JSON document.
Patch-style operation
An add, remove, or replace-style row that describes a path difference.
Numeric coercion
A type policy that can treat a numeric string and the matching JSON number as equal.