What does nesting depth mean?

Depth is how many levels of objects and arrays are stacked inside one another. A high maximum depth often signals a structure that is harder to traverse and reason about.

How is byte size measured?

The tool reports the UTF-8 byte size of the input, which reflects the actual on-the-wire cost, alongside the raw character count.

Does it count duplicate keys?

Yes. It reports total keys and unique keys separately, which helps you notice repeated field names across a large document.

How do I analyze a JSON document?

Paste or upload your JSON and the tool instantly reports its size, maximum nesting depth, key and value counts, and type distribution, turning an opaque payload into a clear profile.

What can JSON statistics tell me?

They help you spot bloat, excessive nesting, unusually large arrays, and the overall type makeup of a document, which is useful before optimizing or debugging performance.

Is my data safe or uploaded anywhere?

All analysis runs locally in your browser and nothing is uploaded, so your data remains private.

JSON Statistics

New

Analyze JSON size, depth, key counts, and type distribution.

Everything is processed locally in your browser

About JSON Statistics

The JSON Statistics tool measures your document and reports metrics that describe its structure and scale. See the total number of keys, the maximum nesting depth, counts by value type, array lengths, and the byte size. It turns an opaque payload into a clear profile you can use to reason about complexity and performance.

Features

Total counts of objects, arrays, keys, and primitive values
Maximum and average nesting depth of the document
Type distribution across strings, numbers, booleans, nulls, and containers
Byte size and character count of the input
Longest arrays and largest objects by member count
Unique versus repeated key analysis

How to use JSON Statistics

1
Paste your JSON
Add the document you want to analyze into the input.
2
Run the analysis
The tool computes size, depth, counts, and type distribution instantly.
3
Review the metrics
Read the breakdown to understand the document's scale and complexity.
4
Act on the insights
Use the findings to spot bloat, deep nesting, or unexpected structure.

Examples

Profiling a small document

Input

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

Output

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

How JSON statistics are calculated

What the numbers actually tell you

Maximum depth is the most immediately actionable figure. Anything beyond five or six levels is hard for people to hold in their heads and hard for code to access without long accessor chains or defensive null checks at every step. Depth above ten usually indicates a structure that grew by accretion rather than design.

The ratio of total keys to unique keys tells you how repetitive the document is. A document with 40,000 total keys and 12 unique ones is an array of 3,000-odd uniform records, which means it is a table and should probably be CSV. A document where the two numbers are close is genuinely heterogeneous.

The type distribution catches contract problems. If a field is a number in most records and a string in a few, you have inconsistent serialisation somewhere upstream - and that is the kind of fault that passes testing and fails on a specific customer's data.

Diagnosing why a payload is too big

When a response is slower than it should be, the useful question is where the bytes are, and statistics answer it faster than reading. Long arrays are the usual culprit - a list endpoint with no pagination that returns everything. Deeply nested repetition is the second, where the same sub-object is embedded hundreds of times instead of being referenced. Oversized string values are the third, and often mean base64-encoded binary data has been smuggled into a JSON field.

Each of those has a different fix, which is why identifying the cause matters more than reaching for compression. Pagination fixes the first, normalising and referencing fixes the second, and moving the payload to object storage with a URL in the JSON fixes the third. Minifying helps none of them meaningfully.

Using statistics before you transform

A quick look at the numbers changes which transformation you reach for. If depth is 1 and the keys are uniform, the document is already tabular and CSV conversion will be clean. If depth is 8, flattening will produce keys like `a.b.c.d.e.f.g.h` that no spreadsheet user will thank you for.

Array length tells you whether flattening is viable at all: a 5,000-element array flattens to at least 5,000 keys, which is technically correct and practically unusable. And knowing the unique key count in advance tells you roughly how many columns a CSV conversion will produce, which is the difference between a usable spreadsheet and one with 400 columns.

Reference

Reading the metrics

Metric	Healthy range	What an outlier suggests
Max depth	1-5	Above 8, accessors get fragile and the shape needs review
Total ÷ unique keys	Near 1 for records	A high ratio means uniform repetition - consider CSV
Longest array	Bounded by a page size	Thousands of elements usually means missing pagination
Type count per field	1	More than one means inconsistent serialisation upstream
Largest string	Under a few KB	Very large strings often hide base64 binary data

Which tool should you use?

These tasks overlap. Here is how to pick the right one for what you are actually doing.

You need to explain why a payload is slow: Start here. The metrics point at the cause - array length, nesting or oversized strings - which determines the fix.
You want to read the actual values: The JSON Tree Viewer is for exploring content. Statistics deliberately reports shape rather than data.
You are deciding whether CSV conversion will work: Check depth and the unique key count first. Shallow and uniform converts cleanly; deep and heterogeneous does not.
You want to know what changed between two documents: The JSON Compare tool reports differences directly.

Use cases

Estimating how heavy an API payload is before optimizing it
Finding excessive nesting depth that could complicate parsing
Auditing how many keys and values a config actually contains
Understanding the type makeup of an unfamiliar dataset
Spotting unusually large arrays that dominate a document's size

Troubleshooting common errors

The unique key count is far lower than the total

Why: The document is an array of uniform records, so the same keys repeat once per element.

Fix: Not a problem - it is a strong signal the data is tabular. CSV will represent it far more compactly.

Reported depth is higher than expected

Why: Arrays count as a level. An array of objects inside an object is already three levels deep.

Fix: Compare against the tree view to see where the levels come from before restructuring anything.

Statistics are slow on a very large file

Why: Every metric requires a full traversal of the parsed document.

Fix: Sample a representative slice. Shape metrics are usually stable across a large uniform document, so a subset is a fair proxy.

A field reports two different types

Why: Inconsistent serialisation upstream - some records emit a number, others a string.

Fix: Fix the producer, and add a JSON Schema to catch it in future. This class of bug is exactly what schemas are for.

Limitations

What this tool deliberately does not do, so you know when to reach for something else.

Statistics describe structure, not content - there is no analysis of what the values mean.
Every metric requires a full traversal, so very large documents are slow.
Duplicate keys collapse during parsing and are therefore not counted.
Byte sizes reflect the parsed document rather than the original text, so whitespace is excluded.
No schema is inferred; use the JSON Schema Generator if you want a formal description.

Frequently asked questions

JSON Tree Viewer

Explore JSON as a collapsible, interactive tree.

Online JSON Formatter & Validator

Pretty-print JSON with configurable indentation and instant validation.

JSON Flattener

Flatten nested JSON into single-level dot-notation key paths.

JSON Compare & Diff

Compare two JSON documents and see a precise structural diff.

Learn more

How to Analyze JSON Structure: Size, Depth, and Type Counts ExplainedA JSON payload can look simple and still hide bloated arrays, dangerous nesting, or dozens of duplicate keys. This guide shows how to profile any document's size, depth, and type makeup before it becomes a problem.