Brotli vs Gzip: Which Compression Should Your Site Use?

Brotli vs Gzip: Which Compression Should Your Site Use?

In the brotli vs gzip debate, the short answer is this: Brotli usually produces smaller files than Gzip for text assets (HTML, CSS, and JavaScript), often 15 to 25 percent smaller, while Gzip is faster to compress and has near-universal support. For files served to browsers and cached, like your CSS and JS bundles, Brotli at a high level is the better choice. For dynamic, on-the-fly responses generated per request, Gzip's speed often wins. Most modern stacks use both: Brotli when the browser supports it, Gzip as the fallback.

This guide explains how each algorithm works, compares them on compression ratio, speed, and browser support, and gives you a clear decision rule for each asset type. We will include a side-by-side comparison table and a worked example so you can see the real-world byte savings. To measure what your own server is actually doing, run any URL through the free GZIP Compression checker and see the encoding and saved bytes instantly, no signup.

What Gzip and Brotli Actually Do

Both are lossless compression algorithms used in HTTP. When a browser requests a page, it sends an Accept-Encoding header listing the formats it understands. The server compresses the response with one of those formats and returns it with a Content-Encoding header. The browser decompresses it before rendering. Nothing is lost; the file is rebuilt byte-for-byte.

Gzip, the long-standing default

Gzip has been the web's compression workhorse since the late 1990s. It is based on the DEFLATE algorithm and is supported by essentially every browser, proxy, and CDN in existence. It offers compression levels from 1 (fastest, least compression) to 9 (slowest, most compression). Its strength is reliability and speed; its weakness is that newer algorithms can squeeze text smaller.

Brotli, the modern challenger

Brotli was developed by Google and released in 2015, designed specifically for the web. Its key advantage is a built-in dictionary of common web strings (frequent HTML tags, CSS properties, and JavaScript keywords), which lets it compress text more aggressively. Brotli offers levels from 0 to 11. At the highest levels it beats Gzip on ratio, but those levels are slow, which is why Brotli is best for files you compress once and serve many times.

The simplest mental model: Gzip is the dependable all-rounder; Brotli is the specialist that compresses web text smaller but takes longer at its best settings.

Brotli vs Gzip: Side-by-Side Comparison

Here is how the two stack up across the dimensions that matter when you choose an encoding.

The headline takeaway: on file size for text, Brotli wins. On raw compression speed and universal compatibility, Gzip wins. Decompression speed in the browser is similar for both, so neither hurts the user's render time once the file arrives.

Compression Ratio: A Worked Example

Numbers make the difference concrete. Consider a typical minified JavaScript bundle with an uncompressed size of 300 KB. Here is roughly how each encoding performs, using common real-world ratios.

The gap between Gzip level 9 and Brotli level 11 here is about 14 KB on a single file. That sounds small, but multiply it across every text asset on a busy site and it adds up to real bandwidth savings and faster first loads, especially on mobile networks. Note that exact numbers vary by content; highly repetitive text compresses far more than already-dense data. Your own results are easy to check by inspecting the response headers and sizes.

Speed: Compression Time vs Decompression Time

This is where the decision gets nuanced, and where many teams pick the wrong tool.

Compression time

Brotli at level 11 can be many times slower to compress than Gzip. For a static asset you build once and cache, that cost is paid a single time and is irrelevant to users. For a dynamic API response generated fresh on every request, paying that cost on every hit would add latency and burn CPU. That is the core trade-off.

Decompression time

Good news: in the browser, decompressing Brotli is roughly as fast as Gzip. The user does not pay a speed penalty for receiving a Brotli file. So the only real cost of Brotli is server-side compression time at high levels, which you eliminate by compressing static assets ahead of time.

Browser and Server Support

Gzip is supported everywhere, full stop. Brotli is supported by all current versions of Chrome, Firefox, Safari, and Edge. The two practical caveats are:

• HTTPS: browsers typically only advertise Brotli (br in Accept-Encoding) over secure connections. On a site without HTTPS, you may only get Gzip.
• Old clients and intermediaries: a very old browser or a misconfigured proxy might not request Brotli. This is exactly why you keep Gzip as the fallback.

On the server side, Brotli support is built into or available for Nginx, Apache, and every major CDN (Cloudflare, Fastly, CloudFront, and others). Most CDNs can even apply Brotli automatically. Because the browser declares what it supports, serving both is safe: each client gets the best format it understands.

When to Use Each: A Decision Rule

You do not have to choose one globally. Match the encoding to the asset:

1. Static text assets (CSS, JS, HTML, SVG, JSON files): use Brotli at level 11, pre-compressed at build time. You pay the slow compression once and serve tiny files forever.
2. Dynamic responses (API JSON, server-rendered pages built per request): use Brotli at a low-to-mid level (4 to 6) or Gzip. The goal is fast compression that still shrinks the payload without adding request latency.
3. Already-compressed files (JPEG, PNG, MP4, WOFF2 fonts, ZIP): do not re-compress. They are already dense, and re-compressing wastes CPU for near-zero savings, sometimes making them slightly larger.
4. Everything, as a safety net: keep Gzip enabled as the fallback so any client that cannot do Brotli still gets compression.

In short: Brotli for cacheable text, Gzip as the universal fallback, and no compression for binary media that is already small.

How to Check What Your Site Is Serving

Before you optimize, measure. You may already be sending uncompressed assets without knowing it. To audit a URL:

1. Run the page through the free GZIP Compression checker to see whether compression is enabled, the encoding used, and the bytes saved.
2. Look at the Content-Encoding response header. br means Brotli, gzip means Gzip, and a missing header means no compression.
3. Compare the compressed size against the original to confirm the savings are reasonable for the content type.
4. If a text asset is uncompressed or only lightly compressed, enable Brotli for static files and Gzip as the fallback in your server or CDN settings.

A single audit often reveals an easy win, like a large JavaScript bundle being served with no encoding at all.

The Bottom Line

Brotli vs Gzip is not really a fight; it is a partnership. Use Brotli at its highest level for static, cacheable text to get the smallest files, fall back to Gzip for universal compatibility and for dynamic responses where compression speed matters, and skip compression entirely for media that is already compressed. That combination gives every visitor the best file size their browser can handle.

Start by finding out what your server does today: run your URL through the free GZIP Compression checker and read the encoding and saved bytes. For more performance and monitoring guides, visit the Website Tracking Tools hub. You may also want our walkthrough on checking an SSL certificate (handy since Brotli needs HTTPS) and our WHOIS lookup guide for inspecting any domain.

Frequently Asked Questions

Is Brotli better than Gzip?

For static text assets like CSS, JavaScript, and HTML, Brotli is generally better because it produces smaller files, often 15 to 25 percent smaller than Gzip. Gzip is better for dynamic responses where fast compression matters and for guaranteed compatibility. Most sites use Brotli with Gzip as a fallback.

How much smaller is Brotli than Gzip?

On typical web text, Brotli at its highest level compresses roughly 15 to 25 percent smaller than Gzip at its highest level. The exact savings depend on the content; highly repetitive text compresses more, while already-dense data shows a smaller gap.

Is Brotli slower than Gzip?

At its highest compression levels, Brotli is significantly slower to compress than Gzip, which is why it is best for static files compressed once and cached. Decompression in the browser, however, is about as fast as Gzip, so users do not pay a speed penalty.

Do all browsers support Brotli?

All current versions of Chrome, Firefox, Safari, and Edge support Brotli, but browsers typically only request it over HTTPS. Keeping Gzip enabled as a fallback ensures any older client or one on a non-secure connection still receives compressed content.

Should I use Brotli or Gzip for dynamic content?

For dynamic, per-request responses, use Gzip or Brotli at a low-to-mid level (around 4 to 6). High-level Brotli is too slow to run on every request and would add latency. Reserve high-level Brotli for static assets you can pre-compress.

Can I use Brotli and Gzip at the same time?

Yes, and you should. The browser tells the server which formats it supports via the Accept-Encoding header, so the server can serve Brotli to clients that support it and Gzip to those that do not. This gives every visitor the best available compression.

Should I compress images with Brotli or Gzip?

No. Formats like JPEG, PNG, MP4, and WOFF2 are already compressed, so applying Brotli or Gzip wastes CPU for almost no savings and can occasionally make them slightly larger. Apply text compression only to text-based assets.

How do I check if my site uses Brotli or Gzip?

Run your URL through a compression checker, or inspect the Content-Encoding response header in your browser's developer tools. A value of br means Brotli, gzip means Gzip, and a missing header means no compression is being applied.