JSON Size Calculator

JSON Size Calculator

How to Use the JSON Size Calculator

1. 1

   Paste the JSON

   Paste a payload into the box, or press "Load sample JSON" to try it with an example. Nothing is uploaded — the measuring happens in your browser.

2. 2

   Read the four size figures

   As pasted, minified, gzipped and the character count. If the byte and character counts differ, the payload contains multi-byte characters.

3. 3

   Check the structure counts

   Keys, arrays and nesting depth. Depth is what tends to matter for parsers and for anything imposing a nesting limit.

4. 4

   Find the expensive keys

   The table ranks top-level keys by size and share of the payload. One key holding 80% of the bytes is the one to paginate, trim or move behind a separate request.

Bytes, characters and why they differ

JSON is transmitted as UTF-8. In UTF-8 an ASCII character takes one byte, most accented Latin and Greek characters take two, most CJK characters take three, and emoji take four. A JavaScript string length counts UTF-16 code units, so it agrees with neither.

This matters whenever a limit is specified in bytes — and almost all of them are. A field capped at "255 characters" in a database is often 255 bytes in practice, and a payload that passes with English text can fail with the same content in Japanese.

The tool reports 1 KB as 1,024 bytes, matching what your operating system shows. Some cloud providers bill and limit using 1,000-byte kilobytes, so a payload right at a documented limit is worth checking both ways.

Size in KB = UTF-8 bytes ÷ 1,024
Size in MB = UTF-8 bytes ÷ 1,048,576
Compression ratio = gzipped bytes ÷ original bytes

Why gzipped size is the number that matters

Nearly every web server and API gateway compresses JSON responses before sending them, and every HTTP client accepts that. So the figure that determines how long a response takes to arrive is the gzipped size, not the raw one.

JSON compresses unusually well because it is so repetitive — the same key names appear in every object of an array. A 1 MB response full of repeated keys routinely compresses to under 100 KB. This is also why minifying a response that is already gzipped buys far less than people expect: gzip was already collapsing that whitespace.

Compression here uses the browser CompressionStream API, so it is a real gzip result rather than an estimate. In a browser without that API the field shows a dash instead of a guess.

Common JSON size limits

Payload limits are one of the most common reasons to measure JSON in the first place. Check the current documentation for your provider before relying on any figure — these move.

Cutting a payload down

• Paginate the biggest array. If one key is most of the payload, a limit-and-offset or cursor parameter fixes it properly, where trimming fields only delays the problem.
• Drop fields the client never reads. Responses accumulate fields over years; the breakdown table shows which ones are worth the audit.
• Shorten key names only as a last resort. Keys repeat once per array element, so shortening them genuinely helps on large arrays — but gzip already compresses the repetition, and unreadable keys cost more in developer time than they save in bytes.
• Return ISO date strings rather than verbose nested date objects, and numbers rather than numeric strings.
• Check whether you are sending nulls for every absent field. Omitting them is usually both smaller and clearer.
• Watch nesting depth. Deeply nested structures cost bytes in punctuation alone and are slower to parse.

Features

• Size in bytes, KB and MB
• Minified and gzipped size
• Biggest keys by share of payload
• Runs in your browser, nothing uploaded

Frequently Asked Questions