OneTaskBy Tim King · Updated
Gzip vs Brotli Size Comparison
Raw, Deflate, Gzip and Brotli Sizes of a Text File, With Percentage Saved
OneTask is free, with no sign-up, and built by one person.
If this tool saved you time, a coffee helps keep new ones coming.
How the Gzip / Brotli Size Comparison works
This gzip vs brotli tool compresses the same file both ways. Every text file a web server sends — HTML, CSS, JavaScript, JSON, SVG — should go out compressed, and the two encodings that matter are gzip and Brotli. Paste a file to see the raw size, what gzip gets it down to, and what Brotli would save on top, with the ratio and the download time on a mobile connection so the difference is in seconds rather than percentages.
Gzip vs brotli: where brotli wins
Text compresses because it repeats. Gzip, which has been in every browser since the 1990s, finds repeated byte sequences and replaces them with short references, then Huffman-codes the result. Brotli, standardised in 2016 and supported by every current browser, does the same with a bigger window and a built-in dictionary of about 120 KB of common web text — tag names, attribute names, CSS properties, English words — so it starts ahead on anything that looks like a web page. On typical assets Brotli output is 10 to 20 percent smaller than gzip, more for HTML and CSS, less for already-dense minified JavaScript.
How the figures are produced. Gzip and deflate are computed in your browser with the CompressionStream API, so those numbers are exact for what you pasted, at the default compression level. Browsers can decompress Brotli but not compress it, so the Brotli figure is an estimate: the gzip size scaled by a ratio typical for the content type you select, based on published benchmarks at Brotli's static-file level 11. Treat it as within a few percent of what your server will produce.
Static versus dynamic. Compression level trades CPU for bytes. Brotli level 11 is slow — far
too slow to run on every request — but it does not matter for static files that are compressed
once at build time and served from disk. For dynamic HTML and API responses servers use Brotli
level 4 or 5 or gzip level 6, which is where Brotli's advantage narrows to a few percent. The usual
setup is pre-compressed .br and .gz files next to each static asset, with the server picking
one from the Accept-Encoding header, and on-the-fly compression at a low level for everything
else.
What not to compress. Images, video, fonts in WOFF2 and anything already zipped are compressed already; running gzip over them wastes CPU and can make them slightly bigger. Most servers are configured to compress only text types. Very small responses, under about 1 KB, gain little because the compression headers and dictionary setup cost a few hundred bytes.
Checking it is on. The response header Content-Encoding: br or Content-Encoding: gzip
confirms compression; its absence on a text file means the server is sending raw bytes and is
usually the single cheapest performance fix available. The HTTP Headers tool on this site fetches
the headers for a URL.
FAQ
Why is the Brotli number an estimate?
Browsers ship a Brotli decoder for receiving pages but not an encoder, and the CompressionStream API only offers gzip and deflate. The estimate scales the exact gzip size by a factor typical for the content type; measured results at level 11 land close to it.
Does compression change how the page renders?
No. The browser decompresses transparently before parsing, and decompression is much faster than the download it saves. The only visible effect is that the page arrives sooner.
What is the difference between deflate and gzip?
The same algorithm. Gzip wraps a deflate stream in a small header and checksum, which is the ten
or so extra bytes you see. Browsers accept both, but Content-Encoding: deflate has a history
of servers sending the wrong wrapper, so gzip is what everyone uses.
Is there anything better than Brotli?
Zstandard is supported in Chrome and Firefox as Content-Encoding: zstd and compresses a little
faster at similar ratios, but Safari does not accept it yet. Brotli remains the safe choice for
the smallest output that every browser understands.
Should I minify as well as compress?
Yes, they stack. Minification removes bytes compression cannot — shortened identifiers, dropped dead code — and compression then handles the repetition. Minify first, then compress; the combined saving is usually larger than either alone.
See also: all Dev Utilities tools, Formatters & Validators, Data & Encoding, Security & Identifiers, SEO, Accessibility, AI.
Related tools
CSS Size Calculator
Measure a stylesheet's real transfer size and see whether it blocks first paint.
JavaScript Size Calculator
See what a script bundle costs to download and to parse on a phone.
Page Weight Calculator
Add up page resources, see the breakdown and load time on each connection.
HTTP Header Inspector
Parse pasted HTTP headers, explain each one and audit security.
SVG Optimizer
Strip editor cruft and round coordinates. See the bytes saved.