Analyse a JSON payload
Runs locallyNode counts, nesting depth and type distribution for any payload.
JSON input
Keys (9)
Every distinct key name in the document, alphabetised.
Reading a payload by its numbers
Size, depth and node count answer different questions. Bytes tell you what the response costs on the wire; depth tells you whether a parser will refuse it; node count predicts parse time far better than bytes do, because the work is per value, not per character. To see where the nodes are, browse the document as a tree.
The most useful number is usually the ratio between them. A 2 MB payload with 40,000 nodes is a large collection and will parse in milliseconds. A 2 MB payload with 900,000 nodes is a pathological shape and will not.
Payload
An array of 5,000 order objects, each with 12 fields and one nested address object of 6 fields
What the numbers say
Nodes ~95,000 Keys 90,000 (18 x 5,000) Depth 4 Bytes ~3.1 MB Gzipped ~280 KB The key names are 18 strings repeated 5,000 times — which is why gzip takes roughly 90% off and why a columnar format would take more.
Where people get caught
Depth is a denial-of-service surface
Most parsers recurse. Jackson, Python json and many others fail somewhere around 1,000 levels, and a few blow the stack instead of raising. A few hundred bytes of nested brackets can take down an endpoint that never checks depth.
Byte size is not transfer size
JSON compresses extremely well because the key names repeat on every record — 80 to 95% is normal. Judge a response budget on the gzipped or brotli size, not the raw one, or you will optimise the wrong thing.
Repeated keys are most of a large payload
In an array of records, the field names are stored once per record. That is the real argument for shortening key names in high-volume APIs, and the reason a columnar or binary format wins so decisively at scale.
Node count predicts parse cost, bytes do not
One 2 MB string is a single node and parses almost instantly. Two megabytes of small values is hundreds of thousands of allocations. If a payload parses slowly for its size, count the nodes.
Deeply nested does not mean large
Depth and size are independent. A shallow million-element array and a 900-level nested object fail for completely different reasons, and a size limit catches only one of them.
About JSON statistics
How it works in 4 steps · 4 common use cases · 3 questions answered
About JSON statistics
How it works in 4 steps · 4 common use cases · 3 questions answered
How it works
- 1.Paste a JSON document.
- 2.It is measured: total nodes, objects, arrays, strings, numbers, booleans and nulls.
- 3.The deepest nesting level, the number of distinct key names and the size in bytes are reported.
- 4.The distinct keys are listed, so you can see the vocabulary of the document at once.
Common use cases
- •Sizing up an unfamiliar API response before writing a parser for it
- •Checking how deep a payload nests before choosing a traversal strategy
- •Comparing two responses by shape rather than by content
- •Finding out how much of a large payload is nulls before deciding to strip them
FAQ
What counts as a node?
Every value in the document, including the container objects and arrays themselves — not only the leaves. It is a measure of total structure rather than of data points.
Is the byte size what my API actually sends?
It is the size of the text you pasted, in UTF-8. A real response is usually smaller on the wire because it is minified and gzipped.
Why does the distinct key count matter?
A payload with three hundred nodes but eight distinct keys is a repeated record shape; one with three hundred distinct keys is a configuration document. They call for very different handling.