JSON Tools

JSON Size Calculator and Analyzer

Measure exactly what a JSON payload costs — raw, minified, pretty-printed and gzipped bytes — and see which keys are eating the budget.

In short

Measure JSON size online: raw, minified, pretty-printed and gzip bytes, plus key counts, nesting depth and the largest keys in your document.

By NaveenKumar T · Updated 10 Sep 2026

Learn: JSON Minify vs Gzip: What Actually Shrinks a Payload

Raw, minified and pretty-printed byte counts
Real gzip and deflate sizes, not estimates
Key count, nesting depth and type breakdown

Runs entirely in your browser — nothing you paste or open here is uploaded, logged, or stored.How we handle data →

Example

JSON Size Calculator: input and output

A small paginated API response — the kind where it is worth knowing whether the payload is really 420 bytes or really 243.

JSON document

{
  "requestId": "req_7f3a91",
  "cached": false,
  "items": [
    { "sku": "KB-75", "name": "Mechanical Keyboard", "price": 149.99, "tags": ["input", "usb-c"] },
    { "sku": "MS-12", "name": "Wireless Mouse", "price": 39.5, "tags": ["input"] },
    { "sku": "HP-40", "name": "Studio Headphones", "price": 199, "tags": ["audio", "wired"] }
  ],
  "page": { "number": 1, "size": 3, "total": 128 },
  "nextCursor": null
}

Size report

JSON SIZE REPORT
================

SIZE
  Raw input                  420 bytes
  Minified                   345 bytes
  Pretty-printed (2 spaces)  582 bytes
  Gzip (of minified)         243 bytes
  Deflate (of minified)      231 bytes

SAVINGS
  Minified vs raw            17.9% smaller
  Gzip vs minified           29.6% smaller

STRUCTURE
  Top-level type             object
  Total keys                 20
  Max depth                  4
  Arrays                     4
  Objects                    5
  Strings                    12
  Numbers                    6
  Booleans                   1
  Nulls                      1
  Longest string             19 chars
  Largest array              3 items

LARGEST TOP-LEVEL KEYS
  items                      236 bytes
  page                       33 bytes
  requestId                  12 bytes
  cached                     5 bytes
  nextCursor                 4 bytes

The document is 420 bytes as pasted and 345 bytes minified — a 17.9% saving — but gzip takes the minified form down to 243 bytes, so compression is doing far more work than minification is. Re-indenting the same data at two spaces would push it to 582 bytes, larger than the input, because the source keeps each item on one line. The items array alone serializes to 236 of the 345 minified bytes, which is where any real size fix has to happen.

Learn more

What the size report measures

Every number in the report is computed from your document in the browser — nothing is uploaded, and nothing is estimated from a formula. The document is parsed first, so a report is also proof that the JSON is valid; if it isn't, you get the line and column of the problem instead of a misleading byte count.

Sizes are reported in UTF-8 bytes rather than characters, because bytes are what travel over the wire and what payload limits are written against. The raw line measures the document exactly as you pasted it, whitespace and all. The minified line re-serializes the parsed value with no spacing at all — the smallest form that is still valid JSON. The pretty-printed line re-indents it at two spaces per level, so you can price a human-readable copy. Gzip and deflate sizes come from the browser's native CompressionStream applied to the minified form; they are real compressed byte counts at the platform's default compression level, so a CDN configured for a higher level, or for Brotli, will land a few percent lower.

Below the sizes, the structure section counts what the document is made of: the top-level type, the total number of object keys at every level, the maximum nesting depth, and how many arrays, objects, strings, numbers, booleans and nulls it contains. The longest string and largest array are called out separately because they are the two values that most often explain a surprising size — an embedded base64 image, or a list that was supposed to be paginated.

What each line of the report tells you
Metric	How it is measured	What to do with it
Raw input	UTF-8 bytes of the text you pasted	Your real starting point, including whatever indentation the producer used
Minified	JSON.stringify with no spacing	The smallest valid form — the baseline for any size budget
Pretty-printed	Re-indented at two spaces	The cost of storing or logging a readable copy
Gzip / deflate	CompressionStream over the minified text	What actually crosses the network once your server compresses
Total keys / max depth	One walk over the parsed value	Parser and validator cost; a signal that a document should be flattened
Longest string / largest array	Maximum over every value in the document	Finds embedded blobs and unpaginated lists
Largest top-level keys	Each top-level value serialized on its own	Tells you exactly which field to drop, page or move behind a second request

Why gzip size is the number that matters for APIs

For anything served over HTTP, the compressed size is the size. Browsers send `Accept-Encoding: gzip, br` on every request and virtually every server or CDN honours it, so the bytes on the wire — and therefore the time your users wait — track the gzip line, not the raw one. This is why chasing whitespace can be disappointing: shortening key names or stripping indentation removes highly repetitive text, which is exactly the text gzip was already removing for free. Measure before you refactor a schema for size.

The uncompressed number still matters, though, because most platform limits are enforced against it. An AWS Lambda synchronous response is capped at 6 MB, an SQS message at 256 KB, a DynamoDB item at 400 KB, and a Kafka broker defaults to roughly 1 MB per message; browser localStorage typically stops around 5 MB per origin. None of those limits care that your payload would have gzipped to a tenth of the size — and base64-encoding a payload to fit it into a field adds another 33% on top. Use the minified line against those ceilings and the gzip line against your latency budget.

When a document is too big, the largest-keys section is where the fix usually lives. In a typical response, one array of records accounts for most of the bytes while the metadata around it is noise; the answer is pagination, a sparse fieldset parameter, or a narrower query — not a shorter key name. If a single string dominates instead, you are almost certainly carrying an inline base64 asset that belongs behind a URL. Once you have made a change, re-run the report and compare, then minify the result or check it with the JSON validator before shipping.

Reading the structure counts

Size is a symptom; structure is the cause. A document with 40,000 keys and a depth of 3 is a large flat dataset, and the fix is pagination. The same byte count with a depth of 12 is a modelling problem: every extra level multiplies the work a parser, a schema validator and every consumer of the data has to do, and deeply nested payloads are the ones that break drivers with nesting limits or blow a recursive serializer's stack.

The type breakdown answers questions that are otherwise guesswork. A high string count against a low number count often means numeric fields are being serialized as text — cheap to fix, and it usually shrinks the document as well. A large null count is a sign of a sparse schema where a leaner representation would carry the same information. And the longest-string figure is the single fastest way to catch an inline base64 image, PDF or signature that someone embedded rather than linking; base64 inflates binary data by roughly 33%, so a 200 KB image becomes 267 KB of JSON that no amount of gzip will rescue.

Because the report is generated from a fully parsed document, all of these counts are exact rather than sampled — the same walk that counts the keys measures the longest string and the largest array. Run it before and after a schema change and the numbers tell you whether the change actually did what you intended.

Help

Frequently asked questions

Everything you need to know about the JSON Size Calculator.

01Does the calculator count characters or bytes?

Bytes, encoded as UTF-8 — the unit your server, storage engine and payload limits actually use. The two only agree for plain ASCII: "café" is four characters but five bytes, a typical emoji costs four bytes, and CJK characters cost three each. Character counts systematically under-report the size of any document containing names, currency symbols or non-Latin text.

02Why is the gzip number so much smaller than the minified number?

Because JSON repeats itself. An array of 500 objects repeats every key name 500 times, and gzip's LZ77 stage replaces each repeat with a short back-reference. The more uniform your records are, the bigger the gap: wide arrays of similar objects routinely compress by 85–95%, while a single small object with unique keys may only compress by 10–30%.

03Why is the pretty-printed size larger than my raw input?

The pretty-printed line always re-indents the document at two spaces per level, expanding every array and object onto its own lines. If you pasted a compact document — or one that keeps short objects on a single line, as most API responses do — re-indenting it genuinely makes it bigger. That row tells you what a human-readable copy would cost, not what your input already costs.

04How is "max depth" counted?

The outermost object or array is depth 1, a container nested inside it is depth 2, and so on; scalars don't add a level. So {"a":1} is depth 1 and {"a":{"b":[1]}} is depth 3. Depth matters because many parsers, schema validators and database drivers impose nesting limits, and deeply nested documents are far more expensive to traverse than wide ones.

05If my server already gzips responses, is minifying still worth it?

Usually a little, rarely a lot — and this report tells you which. Whitespace is highly repetitive, so gzip already removes most of it; run your document through both rows and compare "Gzip (of minified)" against the gzip size of the indented original. Minifying still helps when payloads are stored uncompressed (message queues, database columns, localStorage) or where a size limit is enforced on the uncompressed bytes.

Keep working