What the Compression Savings Estimator does
This estimator compresses your own CSS, JavaScript, HTML, JSON or SVG with gzip and deflate inside your browser and shows the real compressed size of each file, the percentage saved and the transfer time saved at a chosen connection speed. If you also want Brotli, one button measures it on the a2z.tools server - only when you press it.
Published averages for text compression are a poor guide to your files. A minified bundle full of repeated identifiers can shrink by 80%; a JSON file of random IDs or a stylesheet with inlined base64 images may barely move. Measuring the actual bytes tells you whether turning on compression, switching to Brotli or pre-compressing at build time is worth the effort.
How to use it
- Drop up to 20 text files on the drop zone, or paste text and give it a file name so its type can be recognised. Each file may be up to 2 MB.
- Press Measure gzip and deflate. Compression runs in your browser with its built-in CompressionStream, so nothing is uploaded.
- Read the totals and the per-file table: raw size, gzip and deflate sizes, the percentage saved and the milliseconds saved at the connection speed you chose.
- Optionally press the Brotli button. It sends the text to a2z.tools, which compresses it with Brotli and returns only the sizes; nothing is stored. Skip it for anything confidential.
- Open the server hints for Nginx, Apache, IIS or Express, and download the table as CSV.
Reading the results
gzip and deflate use the same DEFLATE algorithm; gzip adds an 18-byte wrapper and deflate (zlib format) a 6-byte one, so gzip is always 12 bytes larger. Browsers accept both, but gzip is the one servers and CDNs use. The browser compresses at zlib's default level, usually 6 - close to what most servers use for on-the-fly compression.
Brotli is measured at the server's highest-quality setting, which is what you would use to pre-compress static files at build time. Servers compressing each response on the fly usually use a lower Brotli level to save CPU, and get a smaller advantage over gzip.
Time saved is raw size minus the best compressed size, converted at the chosen speed with 1 Mbps = 1,000,000 bits per second. It ignores latency, TCP slow start and HTTP/2 multiplexing, so treat it as the order of magnitude, not a page-load prediction.
Worked example: a stylesheet, a script module and a product feed
The first example has three files: components.css (18,980 bytes), format.js (29,140 bytes) and products.json (41,818 bytes), 89,938 bytes in all. gzip brings them to 806, 626 and 5,084 bytes - 6,516 bytes, 92.8% smaller. Brotli, measured on the server, gives 446, 395 and 2,702 bytes: 3,543 bytes, 45.6% less than gzip.
At 10 Mbps the raw files take 89,938 x 8 / 10,000,000 = 72 ms to transfer and the gzipped ones about 5 ms, so compression saves around 67 ms; Brotli saves another 2.4 ms. These example files are unusually repetitive, which is why the ratios are so high. Real bundles more often land at 65-80% with gzip, which is exactly why measuring your own files is worth it.
The JSON shrinks least because each product has unique IDs, SKUs and prices - repetition is what compression feeds on.
Formulas and scoring rules
- Saving
saving = 1 - compressed / rawShown as a percentage, rounded to 1 decimal in the totals and whole numbers in the table.- Compression ratio
ratio = raw / compressed- Transfer time
ms = bytes x 8 / (Mbps x 1,000,000) x 1000Bandwidth only; no latency or protocol overhead.- gzip versus deflate
gzip bytes = deflate (zlib) bytes + 1218-byte gzip header and trailer versus the 6-byte zlib wrapper around the same DEFLATE data.
Limitations: what the result does not prove
- It measures files you supply. It does not check whether your server actually compresses them - use the HTTP Compression Checker on a live URL for that.
- Browser compression uses a fixed default level; servers may use a lower or higher gzip level, and results differ by a few percent.
- The Brotli measurement needs the server and is optional. Do not send secrets, private keys or personal data; paste a representative sample instead.
- Already-compressed formats - images, WOFF2 fonts, video, archives - gain nothing from HTTP compression, and the tool says so rather than showing a misleading saving.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. gzip and deflate run in your browser. Brotli is measured only if you press its button: the browser cannot encode Brotli, so that one step sends the text to a2z.tools, which compresses it, returns the size and keeps nothing. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- RFC 7932 Brotli - checked 19 Sep 2026
- RFC 1952 - GZIP file format
- RFC 1950 - ZLIB Compressed Data Format
- WHATWG Compression Standard - CompressionStream
- Nginx - ngx_http_gzip_module
Frequently asked questions
Is Brotli better than gzip?
For text, usually yes: at high quality it typically produces files 15-25% smaller than gzip, sometimes more on repetitive content. The catch is CPU time at high levels, so the best practice is to pre-compress static files with Brotli at build time and use a moderate level for dynamic responses.
Why can't the browser measure Brotli locally?
The CompressionStream API in browsers supports gzip, deflate and deflate-raw only. Browsers can decode Brotli responses, but they do not offer an encoder to web pages. That is why the Brotli number needs the server, and why it is behind its own button.
What happens to my text when I press the Brotli button?
It is sent over HTTPS to a2z.tools, compressed in memory, and the response contains only the byte counts. Nothing is written to disk or logged with the content. If that is still not acceptable, leave the button alone - the gzip and deflate results never leave your browser.
Should images and fonts be gzipped?
No. PNG, JPEG, WebP, AVIF, WOFF2, MP4 and ZIP are compressed by their own format, so gzip or Brotli add CPU work for a saving of a few bytes or even a slight increase. Restrict HTTP compression to text types such as HTML, CSS, JavaScript, JSON and SVG.
Why is gzip always 12 bytes bigger than deflate here?
Both contain the same DEFLATE-compressed data. gzip wraps it in a 10-byte header and an 8-byte trailer; the zlib format used for Content-Encoding deflate uses a 2-byte header and a 4-byte checksum. The difference is 12 bytes on every file.
Is it worth compressing very small files?
Below about 1 KB the saving is a few hundred bytes at most, and it can be cancelled out by headers and framing. Many servers set a minimum length, such as gzip_min_length 1024 in Nginx, so tiny responses are sent as they are.
Last reviewed by the A2Z.Tools team against the sources listed above.
