Paste JSON to measure exact bytes, KB and MB, see real gzip size, find which keys cost the most, and check it against AWS, GCP and cookie limits.
Try a real payload
Nothing leaves your browser — sizes and compression are measured locally.
Two different questions, two different numbers. Platform limits apply to the uncompressed payload, so the fit check uses your minified size — compressing a 500 KB item does not make it fit a 400 KB ceiling. Gzip tells you what the response costs to send.
AWS states its own quotas in binary units — its DynamoDB documentation spells out that 1 KB means 1024 bytes — so every limit below is compared on that basis.
You might also find these calculators useful
Convert bytes, KB, MB, GB, TB and PB exactly
Convert between bytes, KB, MB, GB, TB, PB
Calculate data compression ratio, space savings, and efficiency
Analyze JavaScript bundle sizes, download times, and performance impact
Paste JSON and get its exact size in bytes, kilobytes and megabytes, the minified size, and the real gzip size measured by your own browser rather than estimated. Then see the part most tools leave out: whether that payload clears the ceilings it will actually meet in production — a DynamoDB item, a Lambda invocation, an SQS message, an HTTP cookie. Everything runs locally, so production data never leaves the page.
A JSON document's size is the number of bytes its text occupies once encoded, almost always as UTF-8. That is not the same as its character count: an accented letter costs two bytes, a currency symbol three, an emoji four. It is also not the same as the size of the objects your program builds after parsing, which is usually far larger. When a platform quotes a limit, it means encoded bytes.
Size in bytes
Confirm a paginated response stays comfortably inside your gateway's payload limit before you raise the page size.
Check a document against a DynamoDB item or Firestore document ceiling before a bulk import fails partway through.
Cookies are capped at 4096 bytes. Measure claims before they silently stop being sent.
See how much gzip actually saves on your real payloads, and which keys to shorten for the biggest win.
Verify a message body fits SQS or Pub/Sub before you design around a limit you have misremembered.
A DynamoDB item is capped at 400 KB and an HTTP cookie at 4096 bytes. Neither cares that your payload compresses well, because the limit applies before any compression.
What you pay to move a response is its gzip or brotli size, not its raw size. Those two numbers can differ by more than tenfold on repetitive data.
Long key names repeated across thousands of array elements, or one oversized description field, typically account for most of a payload. Finding them is faster than guessing.
Compression depends on repetition and entropy, so no formula based on length or character variety can predict it. Only measuring gives you a number you can plan against.
Before. Every limit checked here — DynamoDB items, Lambda invocation payloads, SQS and Pub/Sub messages, Firestore documents, HTTP cookies — is measured on the uncompressed bytes. Compressing a 500 KB item does not make it fit a 400 KB ceiling. Compression only reduces what you pay to transmit a response, which is why this page reports the two numbers separately and checks the limits against the uncompressed size.
Not any more. Amazon's own SQS quota documentation states the maximum message size is 1,048,576 bytes, which is 1 MiB. The 256 KB figure was the older limit and it is still widely repeated in blog posts, tutorials and other calculators. This page uses the current documented value.
AWS documents 6 MB for each of the request and response on a synchronous invocation, 1 MB for an asynchronous invocation, and 200 MB for a streamed response. The asynchronous figure is often quoted as 256 KB, which is out of date.
Gzip output depends on the compressor, its compression level, and its window and dictionary settings, so two implementations can differ by a few percent on the same input. Much larger differences usually mean the other tool is estimating rather than compressing. This page runs your browser's own gzip and reports the byte count it produces.
Gzip adds a header and a checksum, roughly eighteen bytes before any data, and very short inputs offer little repetition to exploit. Below about a hundred bytes the overhead outweighs the saving, so the compressed output is larger than the input. That is normal, and it is why small responses are often sent uncompressed.
Bytes are what limits and bandwidth are measured in. Characters are what a person counts. In UTF-8 an ASCII character is one byte, an accented Latin letter is two, most symbols are three, and an emoji is four. This page shows both, plus the UTF-16 code unit count that JavaScript's string length property returns, which counts an emoji as two.
Cloud vendors generally state quotas in binary multiples while writing the decimal abbreviation. AWS makes this explicit in its DynamoDB documentation, which says 1 KB means 1024 bytes. This page compares against limits on that binary basis and shows each vendor's own wording alongside the figure.
Yes, and it is usually the easiest win available. Removing indentation and newlines does not change your data at all, and on a pretty-printed payload it commonly cuts twenty to thirty percent. Because limits are enforced on the bytes you actually send, the minified size is the number worth optimising.
The ones that repeat. A key name costs its own bytes on every single occurrence, so a fifteen-character name inside a ten-thousand-element array costs well over a hundred and fifty kilobytes in names alone. The breakdown on this page ranks key names by total attributable bytes so the repeated offenders surface first.
Not currently. Browsers expose gzip and deflate for compression but not brotli, so measuring brotli would mean loading a sizeable WebAssembly module. Since gzip is the conservative figure and brotli cannot change any limit verdict, this page measures gzip exactly rather than shipping extra weight for a number that would only look better.
No. Parsing, byte counting and gzip compression all happen in your browser, and the payload is never sent to a server. That matters because the natural thing to paste into a tool like this is a real production response.
A file can carry a byte order mark, a trailing newline, or Windows line endings that use two bytes per break instead of one. Each shifts the byte count slightly without changing the data. This page measures exactly the text you paste, so pasting from an editor that trims or normalises whitespace will give a slightly different figure than the file itself.