JSON Diff
Two documents compared as structures. Indentation, key order and <code>1.0</code> versus <code>1</code> are not differences; added, removed and changed paths are.
Ctrl / Cmd + Enter formats as well.
Click any { } or [ ] to collapse or expand it. The number beside a bracket is its item count, so an empty array is obvious at a glance. Rendering stops at 5,000 nodes.
Paste JSON into the Format & validate tab first.
Supported: $, .key, ..key (recursive descent), [0] and [*]. That is the subset developers actually use, not the whole JSONPath grammar.
Compared structurally, not as text. Indentation, key order and 1.0 vs 1 are not reported as differences.
The data comes from the input box on the Format & validate tab. Supported: type, required, properties, items, enum, const, numeric bounds, string length and pattern, array length and uniqueness, and additionalProperties. Not supported yet: $ref, allOf/anyOf/oneOf and format.
A text diff of two JSON files answers a question nobody is asking. Re-indenting a document, or adding one field at the top, makes every following line "change" — and buries the three differences you came for. A structural diff compares values by path, so it reports config.limits.rate changed from 100 to 500 and nothing else.
This one walks both trees in parallel and emits paths: a.b[2].c, not line numbers. Keys in a different order are equal. 1.0 and 1 are equal, because both parse to the same number.
How arrays are handled, and where it hurts
Arrays are compared by index. That is the correct default for JSON, where array order is part of the data — and it has a sharp edge you should know about before trusting a diff report:
Insert one element at the start of a 10,000-item array and every index shifts, so the
tool reports 10,000 changes. It is not wrong — items[0] genuinely holds a
different value now — but it is not what you meant either. A tool that told you
"one insertion" would have to run a longest-common-subsequence match per array, which is
quadratic, and would be guessing at your semantics.
If you are diffing two API responses where order is not meaningful, sort them first (Sort keys handles objects; arrays are yours), then compare.
What is deliberately not reported
- Whitespace and indentation.
- Object key order.
1.0vs1,1e3vs1000— same number after parsing.- Duplicate keys, which collapse during parsing; the last one is compared.
- Which document a key came from, when one side is missing it — that is reported as a
removal, not as
undefined.
Two documents that differ only in formatting are reported as identical. That is the point of the tool.
Frequently asked questions
Why does it not report indentation differences?
Because it compares parsed values, not bytes. If you want a byte-level comparison of two files, that is a text diff and any editor does it.
I inserted one array element and got hundreds of differences. Bug?
No — arrays are matched by index, so an insertion shifts everything after it. The report is accurate about values at paths; it just is not describing your intent. Sort or align the arrays first if order is not meaningful to you.
Can it compare two files instead of two boxes?
Not onto the diff boxes — only the Format panel has a drop target, and both diff sides are paste-only. Drop the file into Format, copy the result, paste it here. There is no directory or repository mode; for a folder of JSON, use a text diff with a JSON-aware formatter in the pipeline.
Is there a limit on reported differences?
The comparison is complete and so is the display: nothing is silently dropped, which means a 10,000-difference result is a long page. The count at the top is the true total.