JSON Diff Comparator
Compare JSON payloads as parsed structures, find path-level changes, tune array matching, ignore noisy fields, and export review evidence.{{ 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 }}
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.statusor/order/statusthat 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.
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.
- 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.
- 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
.jsonor.txtfile under 4 MB. - 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.
- 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.
- 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, orcode. - 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. - 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:
| 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.
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 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. |
| 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.
References:
- RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format, IETF/RFC Editor, December 2017.
- RFC 6901: JavaScript Object Notation (JSON) Pointer, IETF/RFC Editor, April 2013.
- RFC 6902: JavaScript Object Notation (JSON) Patch, IETF/RFC Editor, April 2013.