Gzip & Brotli Size Estimator

Paste code or text to see its raw, gzipped, and brotli byte size, bytes saved, and compression ratio — the size it would weigh over the wire. Runs entirely in your browser, no server, no sign-up.

Size report

What this tool does

Paste any code or text and instantly see how big it would be after gzip and brotli compression — the size it actually weighs when a server sends it with Content-Encoding: gzip or Content-Encoding: br. You get the raw size, the gzipped size, the bytes saved, the percent reduction, the compression ratio, and a brotli comparison line.

Everything runs locally in your browser. Nothing is uploaded, it works offline, and there is no sign-up.

Why gzipped size matters

The number that affects your page load time is the transfer size — the compressed bytes that travel over the network — not the raw file size on disk. Almost every web server and CDN serves text assets (HTML, CSS, JavaScript, JSON, SVG) with gzip or Brotli, so a 300 KB JavaScript file might only cost ~80 KB on the wire. This tool shows you that compressed number so you can judge a bundle's real weight, compare two versions, or check whether a minification or refactor actually pays off after compression.

How to read the report

FieldMeaning
Raw sizeThe uncompressed UTF-8 byte length of your input.
Gzipped sizeThe size of the gzip stream (header + deflate body + trailer) at the chosen level.
SavedRaw minus gzipped. For very short inputs this can be negative — gzip's ~18-byte header and trailer outweigh any savings.
ReductionBytes saved as a percentage of the raw size.
Compression ratioRaw ÷ gzipped (e.g. 4.00x means it shrank to a quarter).
Brotli sizeThe same input compressed with brotli at quality 11 (Content-Encoding: br), with its own percent reduction — usually a bit smaller than gzip on text.

gzip level

The gzip level (0–9) trades CPU for size. Level 6 is the default used by gzip, zlib, nginx, and most servers — it's the realistic number for production. Level 9 squeezes a little more out at extra CPU cost; level 0 stores the data with no compression. Set the level to match your server if you want an exact estimate.

Notes

FAQ

Why is "Saved" negative for my short snippet?

The gzip container costs roughly 18 bytes of header and trailer before any compression happens. On inputs of a few dozen bytes that overhead outweighs the savings, so the gzip stream is larger than the raw text — which is exactly why servers skip compressing tiny responses.

Is this an estimate or the real transfer size?

The gzip number is byte-exact: your input is actually compressed with the same deflate engine servers use, at the level you chose. It matches the wire size whenever your server uses the same level (6 is the gzip/zlib/nginx default). The brotli line uses quality 11 — typical for pre-compressed static assets; CDNs compressing on the fly often use a lower quality, so their br size can be slightly larger.

Which gzip level should I set?

Leave it at 6 to mirror a stock server config. Use 9 if your build pre-compresses assets at max effort, and 0 to see the stored (uncompressed) framing size. Values outside 0–9 are clamped into range. The level trades CPU for size — 9 usually buys only a few percent over 6.

Are the KB figures decimal or binary?

Binary — 1 KB = 1024 bytes, the same convention as browser dev tools, so you can compare the report directly with the Network panel. Exact byte counts are shown alongside every human-readable size.

Developer & Automation Access

Run it from the terminal

Same engine as this page, headless — via the gizza CLI:

gizza tool gzip-size-estimator "Paste your JS, CSS, JSON, or any text here…"

New to the CLI? Get gizza →

Open it by URL

Pre-fill and auto-run this tool with query parameters — the names match the API/CLI:

https://gizza.ai/tools/gzip-size-estimator/?input=Paste%20your%20JS%2C%20CSS%2C%20JSON%2C%20or%20any%20text%20here%E2%80%A6&level=6

Machine-readable descriptor: tool.json — title + parameters JSON Schema for agents.