Knowledge
Brotli vs Gzip: which compression should you use?
#Performance
Brotli vs Gzip is the practical choice for compressing text responses. Here is how the two differ on ratio, speed, and support, and which one to serve.
Published by Mark van Eijk on June 23, 2026 · 3 minute read
- What Gzip is
- What Brotli is
- Compression ratio
- Speed and levels
- Browser support
- Recommendation
- How to enable it
- Conclusion
Both Brotli and Gzip do the same job: they shrink text responses (HTML, CSS, JS, JSON) before sending them over the wire so pages load faster on the client. The Brotli vs Gzip question isn't really "which is better" in the abstract, it's which one to use for which kind of asset. This guide covers the practical differences in ratio, speed, and browser support, then gives a recommendation you can act on.
What Gzip is
Gzip is the long-standing standard for HTTP compression. It's built on the DEFLATE algorithm (LZ77 plus Huffman coding) and has been supported by every browser and server worth caring about for two decades.
Its strengths are universal support and speed. Gzip compresses quickly even at higher levels, so it's safe to use on dynamic responses generated per request. It's the safe default that works everywhere.
What Brotli is
Brotli is a newer algorithm developed at Google, designed specifically with the web in mind. It uses similar techniques to DEFLATE but adds a few things that pay off on text: larger compression windows, context modelling, and a built-in dictionary of common words and HTML/CSS/JS fragments.
That built-in dictionary is the key difference. Because web responses share a lot of boilerplate, Brotli can reference common strings without spending bytes describing them, which is why it tends to beat Gzip on exactly the content most sites serve.
Compression ratio
On text, Brotli generally produces smaller output than Gzip at comparable settings, often in the rough range of 15-25% smaller for HTML, CSS, and JS. The exact savings depend heavily on the file and the levels you compare, so treat that as a ballpark rather than a guarantee.
The gain is largest on text-heavy assets. For already-compressed binaries (images, fonts in WOFF2, video) neither algorithm helps much, so don't bother compressing those.
Speed and levels
This is where the choice actually gets decided.
- Gzip runs at levels 1-9. Higher means smaller but slower; the middle levels are a good balance for on-the-fly compression.
- Brotli runs at levels 0-11. The top level (11) squeezes out the best ratio but is slow to compress — far slower than Gzip.
That speed cost shapes how you use each one:
| Scenario | Best choice | | --- | --- | | Static assets (CSS/JS bundles) | Brotli at level 11, precompressed at build time | | Dynamic responses (HTML, API JSON) | Brotli at a low level, or Gzip | | Maximum compatibility | Gzip as the fallback |
The insight: Brotli 11 is expensive to run once but cheap to serve forever, so it's ideal for static, precompressed assets. For dynamic responses you pay the cost on every request, so a lower Brotli level or plain Gzip is the better trade.
Browser support
Both are effectively universal in modern browsers. Gzip works everywhere. Brotli is supported by all current browsers, with the one caveat that they only advertise it over HTTPS.
The browser tells the server what it accepts in the Accept-Encoding request header:
Accept-Encoding: br, gzip
br is Brotli. The server picks the best encoding it supports from that list and signals its choice back in the Content-Encoding response header. If a client only sends gzip, you fall back to Gzip automatically.
Recommendation
You don't have to pick one. Serve Brotli when the client supports it, with Gzip as the fallback — this is how a well-configured server already behaves based on Accept-Encoding.
The one decision worth making deliberately:
- Static assets (your built CSS/JS): precompress them at build time with Brotli at level 11. The server then serves the
.brfile directly with no per-request cost. - Dynamic responses (HTML, JSON APIs): use a low Brotli level or Gzip so compression doesn't add latency to time to first byte.
Compression is one of the highest-leverage things you can do for overall site performance, and it costs almost nothing to turn on.
How to enable it
On Nginx, both algorithms are configured in a few lines. The Gzip side is covered step by step in enable Gzip compression on Nginx; Brotli works the same way once the ngx_brotli module is loaded, with directives for both dynamic compression and serving precompressed .br files.
Conclusion
In the Brotli vs Gzip comparison there's no real loser. Brotli wins on ratio for text and is the right choice for precompressed static assets at level 11. Gzip is the universal, fast fallback that's hard to go wrong with. Configure your server to prefer Brotli and fall back to Gzip, precompress your static bundles, and skip compressing already-compressed binaries.
Subscribe to our newsletter
Do you want to receive regular updates with fresh and exclusive content to learn more about web development, hosting, security and performance? Subscribe now!
Related articles
How to optimize server performance
Brotli vs Gzip is the practical choice for compressing text responses. Here is how the two differ on ratio, speed, and support, and which one to serve.
How to measure TTFB (Time To First Byte)
Brotli vs Gzip is the practical choice for compressing text responses. Here is how the two differ on ratio, speed, and support, and which one to serve.