Also available in: Español · Português · Français · العربية
Gzip Size Checker: gzip, brotli and deflate
Paste anything and see its compressed size in every format your browser can produce, with the gzip figure put in its place.
What is gzip size?
Gzip size is how many bytes a file becomes after compression — the number that actually crosses the network, as opposed to the number the file occupies on disk. It is the figure performance budgets are written in, because a 300 KB JavaScript bundle that compresses to 80 KB costs a visitor 80 KB.
Compression works by finding repetition. That is why the same trick gives wildly different results on different content: markup and JSON repeat themselves constantly and shrink enormously, while prose repeats itself far less and shrinks modestly. An image or a zip file has already had its repetition removed and will barely move at all.
This page compresses what you give it in every format your browser supports, and shows the sizes side by side. It runs entirely in the browser, so nothing you paste or select leaves your machine.
How to use it
- Paste text, or choose a file. Either works. A file is read locally and never uploaded, so its size is limited only by what your own machine will hold.
- Read the sizes across the formats. Each row gives the compressed size, the ratio against the original, and the bytes saved. The smallest is marked.
- Check what your browser refused. The line under the table names any format your browser would not produce, because the standard allows an implementation to support fewer than all four.
The gzip number is not the number that ships
Almost every size checker reports gzip and stops. Meanwhile the CDN in front of a modern site is usually serving brotli, which is a different algorithm with a different result — and it is consistently smaller.
Measured on this site's own source files, brotli came out between 16% and 28% smaller than gzip. That is not a rounding difference. If your budget says 100 KB gzipped and your CDN serves brotli, you have been measuring something you do not ship, and being pessimistic about it by a fifth.
The Compression Streams standard that browsers implement defines exactly four formats: brotli, deflate, deflate-raw and gzip. There is a trap in the naming, because HTTP does not use those words — in an Accept-Encoding header brotli is spelled br, and asking a browser for br rather than brotli throws an error rather than compressing anything.
Compression can make a file bigger
Every format wraps its output in a container, and the container has a fixed cost. Compressing nothing at all — an empty input — still produces 20 bytes of gzip, 8 bytes of deflate, 2 bytes of deflate-raw and 1 byte of brotli. That is the floor beneath every measurement on this page.
On input that cannot compress, the cost is small but real. Feed the deflate family bytes with no pattern in them and the output is 23 bytes larger than the input, plus another 5 for every 64 KB block after the first; brotli manages the same job for 4. This is why compressing an already-compressed file is a waste, and why a server that gzips a JPEG is making the response slightly worse rather than better.
The practical consequence is for small responses. A 200-byte JSON API reply is a case where the container may cost more than the compression saves, and the tool will show you a negative saving when that happens rather than hiding it.
What this page cannot tell you
It cannot tell you the exact bytes your server will send. Compression has effort levels, and the browser's compressor exposes none of them — you get whatever the implementation chooses, while a CDN may be tuned harder or softer. Two correct implementations of the same format legitimately produce different sizes for the same input.
It also measures one file at a time, in isolation. Real transfer sizes are affected by whether a response is compressed at all below some threshold, by the connection's own framing, and for many small assets by whether they were bundled together first — several files compressed as one almost always beat the same files compressed separately, because the repetition between them becomes available.
And the format list is whatever your browser supports today. The line under the table reports that rather than assuming it, because the standard explicitly permits an implementation to refuse a format, and different browsers do.
Why is it free?
The compression is done by an API your browser already has. Nothing you paste or select is uploaded, nothing is logged, and there is no account to make.
No sign-up, no limits, and no watermark on anything you copy out.