Brotli vs Gzip: which one should your server use?
Both shrink your text before it hits the wire, and both are basically free speed. The honest comparison — which compresses harder, which is faster, and why the answer depends on whether the file is cacheable.
The short answer, so you can stop reading if that is all you needed: offer both, and let the browser pick. Serve static files Brotli-compressed at a high setting and cache the result; serve dynamic responses with Gzip or low-level Brotli. Every browser released in the last decade supports both, so there is no compatibility reason to choose.
The longer answer is more interesting, because "Brotli is newer so use Brotli" is exactly the kind of advice that makes a busy API server 20% slower.
What compression is doing
Text is wildly repetitive. HTML, CSS, JavaScript and JSON repeat the same tags, class names, keywords and whitespace patterns thousands of times in a file. Both Gzip and Brotli find those repeats and encode them compactly, so a 200 KB file travels as 40-something KB and the browser rebuilds it on arrival. Less data on the wire means faster loads, and the effect is largest exactly where it matters most — mobile connections.
Compression only helps text. JPEG, PNG, WebP, MP4 and WOFF2 are already compressed — running Gzip over them burns CPU for a fraction of a percent, and can occasionally make the file bigger. Compress text; optimise media separately.
The comparison
| Gzip | Brotli | |
|---|---|---|
| Released | 1992 | 2015 |
| Compression levels | 1–9 | 0–11 |
| Typical text savings | ~70% | ~75–80% |
| Built-in dictionary | No | Yes — common web strings |
| Speed at maximum setting | Fast | Much slower |
| Speed at low settings | Fast | Comparable |
| Browser support | Universal | Universal (since ~2016) |
| Works over plain HTTP | Yes | HTTPS only in practice |
Brotli's edge comes partly from a better algorithm and partly from something clever: it ships with a built-in dictionary of about 13,000 common web strings — things like </div>, function, charset=utf-8. Those cost almost nothing to encode because both sides already have them. It is why Brotli's advantage is largest on small files, where Gzip has not yet had a chance to build up its own dictionary from the content.
Why the newer one is not always the right one
Here is the part that decides your configuration. Brotli at level 11 is dramatically slower to compress than Gzip — often an order of magnitude or more. Decompression is fast either way; it is the compression side that costs.
Whether that matters depends entirely on how many times the compressed output gets used.
For a static, cacheable file — your CSS bundle, your app JavaScript, a font-free HTML page that rarely changes — you compress once and serve that same compressed copy thousands or millions of times. The slow compression happens one time, at build or on first request, and no visitor ever waits for it. Use Brotli 11. There is no downside.
For a response generated per request — a personalised dashboard, an API endpoint, a search results page — there is no reuse. Every response is compressed fresh, and Brotli 11 would add measurable latency and CPU to every single one. Here you want Gzip at a middling level, or Brotli at 4 or 5, which is roughly Gzip-speed while still compressing slightly better.
The classic mistake is enabling Brotli at its default maximum on a dynamic app server and then wondering why response times got worse under load. If you take one number from this article: 11 for cacheable, 4–5 for on-the-fly.
Checking what you actually serve
Configuration and reality drift apart surprisingly often — a proxy strips the header, a rule only matches some content types, someone turned it off during an incident in 2023. One command tells you the truth:
curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/app.css | grep -i content-encodingIf nothing comes back, you are shipping uncompressed text. Try it against your HTML, your main stylesheet and your largest JavaScript bundle — it is common for one of the three to have been missed.
Where zstd fits in
A third name has been turning up in this conversation: zstd, or Zstandard. Chrome and Firefox both support it as a content encoding now, and it is worth knowing what it is for, because the framing is different from Brotli.
Brotli's pitch is "smaller than Gzip". Zstd's pitch is "much faster than Brotli at similar ratios". At the low-to-middle settings you would use for dynamic responses, zstd compresses considerably faster than either of the others for roughly the same output size, which makes it interesting exactly where Brotli 11 is a bad idea — per-request content generated on the fly.
For static cacheable files, Brotli 11 still generally wins on size, and since compression time does not matter there, it stays the right choice. So the shape of the answer does not really change; zstd is a better option for the dynamic half than Gzip is, on clients that support it.
Support is good but not universal, and Safari has been slower to adopt it than the others. That is fine — content negotiation means you offer it and clients that do not understand it simply get Brotli or Gzip instead. It is additive, not a migration.
You do not actually have to choose
Browsers advertise what they support on every request via the Accept-Encoding header. A CDN reads that and serves the best option the client can handle — Brotli where available, Gzip as a fallback — and caches both variants separately, keyed by encoding. You enable it once and the right thing happens per visitor, forever.
Which is really the answer to the question in the title. "Brotli vs Gzip" frames it as a decision, and it has not been one for years. The decision worth making is the compression level, and that depends on whether the thing you are compressing will be reused.
Quick answers
Is Brotli better than Gzip?
Brotli compresses text roughly 15 to 20 percent smaller than Gzip, so for files you compress once and serve many times it is clearly better. For responses generated fresh on every request, Brotli at its highest setting is far slower than Gzip and will add latency under load. The right answer is to offer both and vary the compression level by whether the content is cacheable.
What Brotli compression level should I use?
Use level 11 for static cacheable assets such as CSS and JavaScript bundles, where the slow compression happens once and the result is reused. Use level 4 or 5 for dynamic per-request responses, which is roughly Gzip speed while still compressing slightly better. Level 11 on dynamic content is the most common misconfiguration and it measurably increases response times.
Do all browsers support Brotli?
Yes, every current browser has supported Brotli since around 2016, including Chrome, Firefox, Safari and Edge. Browsers advertise support in the Accept-Encoding request header, so a server or CDN can serve Brotli to clients that accept it and fall back to Gzip for anything that does not. There is no compatibility reason to avoid it.
Should I compress images with Gzip or Brotli?
No. JPEG, PNG, WebP, AVIF, MP4 and WOFF2 files are already compressed, so running Gzip or Brotli over them consumes CPU for a negligible saving and occasionally makes the file slightly larger. Compress text formats such as HTML, CSS, JavaScript, JSON and SVG, and handle images separately through format conversion and resizing.
Offer both encodings. Compress cacheable static files hard with Brotli 11 and let them be reused; compress per-request responses lightly with Gzip or Brotli 4–5. Never compress images or video. Then run one curl command to confirm what you configured is what you are actually serving.
See how NordicCDN does this for your site:
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
