Reading the summary
As pasted is the UTF-8 size of exactly what is in the editor, whitespace included. Minified is the same data with every optional space and newline removed, and Pretty is the data indented by two spaces, one value per line. The gap between the last two is pure formatting: it is what a server saves by not pretty-printing responses, before any compression.
Every size is counted in bytes, not characters. An accented letter takes two bytes in UTF-8, most CJK characters take three and an emoji takes four, so a short string in Japanese can outweigh a longer one in English. Numbers and escapes are counted as written: 1.50 stays four bytes and \u00e9 stays six, which is also how the JSON minifier prints them.
The coloured bar splits the minified bytes into string values, key names, numbers, the literals true, false and null, and the brackets, colons and commas that hold it all together.
Finding the heavy paths
The table lists subtrees by minified size, each with its share of the whole document. Three views answer different questions:
- Largest subtrees ranks every object, array and value below the root. Parents always outrank their children, so read down the list to see which branch the bytes sit in.
- Top-level members splits the root into its direct members or items, the usual first question for an API response.
- Fields across items adds up each field over every element of every array, written as
$.users[*].email. This is the view that shows that one optional field, repeated across ten thousand records, costs more than everything else combined.
Click any path to copy it as JSONPath, then paste it into the JSON Path Finder to look at the data there. Columns sort when you click their headings.
Key-name overhead
JSON repeats every key in every object. In an array of records the names can take a third of the payload or more, especially with long, prefixed names like user_created_at. The key table ranks names by the total bytes they cost, quotes and colon included, with the number of times each one appears.
If the overhead is high, there are three common remedies: shorter field names in the API contract, a columnar shape that lists names once ({"columns": [...], "rows": [[...]]}), or a different format for bulk exports. A JSON to CSV converter writes the names once in a header row. Compression with gzip or Brotli removes most repetition on the wire, but the parsed size in memory and the cost of parsing stay the same.
Depth, strings and arrays
The depth table counts nodes at each level, with the root at depth 0. A long tail of deep levels usually means wrapper objects that carry little data. Longest strings finds embedded blobs such as Base64 images, HTML fragments and stack traces, which are often the single biggest item in a payload and a good candidate for a separate download. Arrays with the most items shows where pagination or a limit parameter would help most.
Accuracy, limits and privacy
The analysis is one streaming pass over the text in a background worker, without building the data in memory, so multi-megabyte files are measured in about a second and 100,000 levels of nesting are fine. Totals are exact: the test suite checks them against the formatter’s own minified and two-space output on thousands of generated documents.
The input must be strict JSON. If it has comments, single quotes or trailing commas, the error shows the line and column; the JSON validator can explain the problem in more detail. Nothing is uploaded, and the page keeps working offline.
Examples
A paginated API response with long key names
Four user records whose keys all start with “user_”. The key table shows the names costing more bytes than many of the values they label.
{
"page": 1,
"per_page": 4,
"users": [
{ "user_id": 101, "user_name": "ada", "user_email": "ada@example.com", "user_is_active": true, "user_created_at": "2026-01-04T09:12:00Z" },
{ "user_id": 102, "user_name": "grace", "user_email": "grace@example.com", "user_is_active": true, "user_created_at": "2026-02-11T14:30:00Z" },
{ "user_id": 103, "user_name": "linus", "user_email": "linus@example.com", "user_is_active": false, "user_created_at": "2026-03-19T08:05:00Z" },
{ "user_id": 104, "user_name": "margaret", "user_email": "margaret@example.com", "user_is_active": true, "user_created_at": "2026-04-27T17:45:00Z" }
]
}Minified 564 bytes, pretty 781 bytes: minifying saves 27.8%
Largest subtree: $.users (532 bytes, 94.3%)
Key names: 306 bytes (54.3%); costliest key "user_created_at" × 4
Longest string: $.users[0].user_created_at (22 bytes)An embedded Base64 thumbnail
One image encoded inline as Base64 dominates the response. It tops the largest-subtree table and the longest-strings list.
{
"product": { "sku": "LMP-220", "name": "Desk lamp", "price": 39.9 },
"images": [
{
"kind": "thumbnail",
"mime": "image/png",
"data": "iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAyRpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2LjE0NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4="
}
],
"reviews": { "count": 2, "average": 4.5 }
}Minified 510 bytes, pretty 597 bytes: minifying saves 14.6%
Largest subtree: $.images (403 bytes, 79.0%)
Key names: 89 bytes (17.5%); costliest key "product" × 1
Longest string: $.images[0].data (354 bytes)A nested service configuration
Per-region settings three levels deep and no arrays of records, so the top-level view tells the story: the regions block holds most of the bytes, and key names outweigh the values.
{
"service": "checkout",
"regions": {
"eu-west-1": { "replicas": 3, "limits": { "cpu": "500m", "memory": "512Mi" } },
"us-east-1": { "replicas": 5, "limits": { "cpu": "1000m", "memory": "1Gi" } },
"ap-southeast-1": { "replicas": 2, "limits": { "cpu": "500m", "memory": "512Mi" } }
},
"features": ["express-pay", "gift-cards", "saved-addresses"]
}Minified 300 bytes, pretty 497 bytes: minifying saves 39.6%
Largest subtree: $.regions (209 bytes, 69.7%)
Key names: 177 bytes (59.0%); costliest key "replicas" × 3
Longest string: $.features[2] (17 bytes)Common errors and how to fix them
| Error | Cause | Fix |
|---|---|---|
Trailing comma before '}'Explained | The analyser reads strict JSON, and the input has a comma after the last member of an object. | Remove the comma, or repair the document first with the JSON formatter’s Fix it button. |
Comments are not allowed in JSONExplained | The text is JSON with comments (JSONC), as used by tsconfig.json and VS Code settings. | Convert it with the JSONC to JSON converter, then paste the result here. |
Minified size is larger than expected | Sizes count UTF-8 bytes. Non-Latin text, emoji and \u escapes take several bytes per character. | Check the longest strings list. Writing characters directly instead of as \u escapes usually saves space. |
Frequently asked questions
Does the size include gzip or Brotli compression?
No. All sizes are uncompressed UTF-8 bytes. Compression shrinks repeated key names dramatically on the network, but the receiver still parses and holds the full uncompressed text.
Why do sizes in the table add up to more than 100%?
Largest subtrees include parents and their children: a list and the items inside it both appear, and the items are part of the list. Use the top-level view for shares that add up.
What counts as key-name overhead?
Every byte used to write member names: the name, its quotes, any escapes and the colon after it. Whitespace is not included because sizes are measured on the minified form.
Is depth counted from 0 or 1?
The root value is depth 0, its members or items are depth 1, and so on. A flat array of numbers therefore has a deepest level of 1.
How large a file can I analyse?
Tens of megabytes work, limited mainly by browser memory for the text itself. The analysis runs in a worker, so the page stays responsive while it works.