How to Analyze JSON Structure: Size, Depth, and Type Counts Explained

JSON statistics are structural metrics computed by walking a parsed document and tallying what it contains: how many objects and arrays exist, how many keys appear in total versus how many are unique, how deeply things are nested, and how the leaf values break down by type (string, number, boolean, null). None of this changes the data - it is read-only analysis, the same way wc counts lines in a text file without altering it.

The result is a compact summary that tells you far more about a document's shape than scrolling through it ever could. Two payloads can have similar byte sizes yet completely different profiles: one might be a flat list of a thousand simple records, the other a deeply nested tree of twenty fields. Those two documents behave very differently in code, and statistics make that difference visible immediately.

{
  "users": [
    { "id": 1, "active": true },
    { "id": 2, "active": false }
  ]
}

Keys: 5 | Objects: 3 | Arrays: 1
Max depth: 3
Types: number 2, boolean 2, array 1, object 3

Most JSON problems are structural before they are semantic. An API that suddenly returns 40 keys per object instead of 12 is a schema drift worth catching. A config file where nesting depth jumped from 3 to 9 is a maintainability regression waiting to bite the next engineer who edits it. Statistics turn these changes from invisible to obvious.

• Performance triage - a huge byte size or a handful of arrays with thousands of entries often explains a slow endpoint or a laggy UI render better than a profiler trace does.
• Schema sanity checks - unique key counts versus total key counts reveal whether a document's shape is consistent or wildly variable across records.
• Complexity budgeting - maximum nesting depth is a proxy for how hard a structure is to traverse, serialize, and debug by hand.
• Change review - comparing statistics before and after an API change or refactor is a fast sanity check that nothing ballooned unexpectedly.

Under the hood, the process starts the same way any JSON tool starts: parse the text into an in-memory tree of objects, arrays, and primitive values. From there, the analyzer walks the tree once, keeping running tallies as it goes - incrementing an object counter each time it enters an object, an array counter for arrays, and a type counter for every leaf value it reaches (string, number, boolean, or null).

Depth is tracked by passing the current nesting level down through the walk and recording the highest value seen. Key counts work the same way, with a running total for every key encountered and a separate set that only grows when a key name has not been seen before, which is how the tool distinguishes total keys from unique keys. Byte size is measured from the UTF-8 encoding of the raw input, since that reflects the real cost of sending the payload over the wire rather than just its character count.

1. Open JSON Statistics and paste in the document you want to understand - an API response, a config file, or a data export.
2. Let the tool parse and walk the structure. If the input is invalid, you will see that immediately rather than a silent, misleading count.
3. Review the summary: total objects, arrays, keys, unique keys, maximum depth, and the type breakdown of every leaf value.
4. Check the byte size and character count if you are evaluating payload weight for an API or storage limit.
5. Look for outliers - an unusually deep nesting level, a very large array, or a big gap between total keys and unique keys - and investigate the part of the document responsible.

There is nothing to configure and no account required. Paste, read, done - and it keeps working offline once the page has loaded, since all of the counting happens on your own machine.

• Estimating how heavy an API payload is before deciding whether it needs pagination or compression.
• Finding excessive nesting depth in a config file that would make manual edits error-prone.
• Auditing how many fields a document actually contains before writing a schema or TypeScript interface for it.
• Understanding the type makeup of a dataset you did not produce yourself, before writing code that assumes a shape.
• Spotting a single oversized array that is quietly responsible for most of a document's byte size.
• Comparing two versions of the same payload structure to confirm a refactor did not introduce unwanted bloat.

Confusing byte size with character count

For plain ASCII JSON, byte size and character count are the same number, so it is easy to assume they always match. Once a document contains non-ASCII characters - accented names, emoji, or non-Latin scripts - each character can take two, three, or even four bytes in UTF-8. If you are estimating network or storage cost, use the byte size, not the character count.

Treating maximum depth as typical depth

Maximum nesting depth tells you the worst case, not the norm. A document can have a single deeply nested branch (say, one error object with a long cause chain) while the rest of the structure is shallow. Before assuming a whole schema is overly complex, check whether the deep path is an outlier or a pattern repeated throughout the document.

Ignoring the gap between total and unique keys

A large difference between total keys and unique keys usually just means the same field names repeat across many array items - id, name, and active appearing once per record is expected and healthy. But if unique keys keep climbing close to total keys as the document grows, that can signal inconsistent field names across records, which is worth fixing before it complicates a schema.

• Profile large or unfamiliar API responses before writing code against them, so assumptions about shape are based on data rather than a single example.
• Set a rough depth budget for config formats your team maintains, and re-check it with JSON Statistics whenever a config grows.
• Pair statistics with the JSON Tree Viewer when you need to see exactly where a large array or deep branch lives, not just that it exists.
• If a document turns out to be bloated by one huge array, consider whether flattening or restructuring the payload would make it easier to consume.
• Re-run the analysis after any schema change or refactor as a quick regression check - a jump in depth or key count is often the first sign something drifted.