Cloudflare extends Brotli from origin to edge
Compression reduces the number of bytes that travel across the Internet, which translates into faster page loads and lower bandwidth costs. Cloudflare has supported Gzip for all users since the company's early days, and Brotli for the edge-to-browser connection since 2017. Now Cloudflare is closing the loop: Brotli can be served end-to-end, from origin server to end user, at compression levels up to 11.
Brotli offers 12 compression levels (0–11). Level 0 is fastest but yields the lowest compression ratio; level 11 produces the smallest files but demands the most CPU time. When Cloudflare first implemented Brotli five years ago, the company determined that level 4 offered the best trade-off between bytes saved and compression time. That remains Cloudflare's default for compressing assets from the edge.
The gap was on the origin side. Cloudflare previously requested only Gzip from origin servers and decompressed everything it received before recompressing for the client. Even if an origin supported Brotli, that capability went unused. With the new end-to-end support, Cloudflare sends an updated accept-encoding header to origins. Customers can then transfer, cache, and serve Brotli-compressed content at any level, including the maximum level 11.
If the end user's browser does not support Brotli, Cloudflare decompresses the file automatically and serves it either uncompressed or as Gzip, based on the client's Accept-Encoding header.
When end-to-end Brotli is bypassed
Certain Cloudflare proxy features require access to the response body, which forces decompression. Customers who want full end-to-end Brotli must disable the following features:
- Email Obfuscation
- Rocket Loader
- Server Side Excludes (SSE)
- Mirage
- HTML Minification — JavaScript and CSS minification can remain enabled
- Automatic HTTPS Rewrites
With any of these features active, an origin can still send Brotli at higher levels, but Cloudflare will decompress, apply the features, and recompress on the fly using its default settings: Brotli level 4 or Gzip level 8, depending on the client's accept-encoding header.
Compression measurements
Testing against a simple CSS file shows the size differences across algorithms and levels. Brotli level 11 produces files roughly 19% smaller than the best Gzip compression level and about 18% smaller than Cloudflare's default Brotli level 4.
| Test | Size (bytes) | % Reduction of original file (Higher % better) |
|---|---|---|
| Uncompressed response (no compression used) | 2,747 | - |
| Cloudflare default Gzip compression (level 8) | 1,121 | 59.21% |
| Cloudflare default Brotli compression (level 4) | 1,110 | 59.58% |
| Compressed with max Gzip level (level 9) | 1,121 | 59.21% |
| Compressed with max Brotli level (level 11) | 909 | 66.94% |
Those savings matter for performance and for egress fees, which scale with bytes transferred from cloud providers.
Implementation details
Enabling origin-side Brotli required building a decompression module that integrates into Cloudflare's software stack. The decompressor lives in the core reverse proxy so any Cloudflare product or feature can access Brotli-compressed bodies. That integration also lets Cloudflare Workers interact with Brotli responses or pass them through unmodified to the end user.
Compression Rules for granular control
Alongside end-to-end Brotli, Cloudflare is introducing Compression Rules for Enterprise customers. The rules give administrators control over how and what Cloudflare compresses to end users, using the same filter infrastructure as other Cloudflare rules products, with added fields for Media Type and Extension type.
Use cases include enabling compression for .ktx files to optimize WebGL texture delivery, disabling compression entirely for specific content, or setting encoding preferences per hostname — for example, Gzip only for IoT devices and Brotli for everything else.
Compression Rules are available now. End-to-end Brotli is rolling out over the coming weeks.
Brotli toggle deprecation
When Cloudflare introduced Brotli in 2017, browser support was uneven, so customers could toggle the feature on or off via the API and dashboard. Brotli is now supported by all major browsers, and Cloudflare plans to enable it on all zones by default in the coming months, matching the behavior of Gzip. The dashboard toggle will be removed. Browsers that do not support Brotli will still receive Gzip or uncompressed responses, and Enterprise customers can use Compression Rules to control compression toward their users.
Looking ahead: shared dictionaries and zstd
Cloudflare is monitoring newer compression algorithms, including zstd, as possible next-generation options. The company is also researching shared dictionaries for Brotli. The Brotli RFC defines a static dictionary used by both clients and origins; a bespoke dictionary tailored to a specific website could compress repeated site-specific words and phrases more aggressively. A proposal from the Web Incubator CG would let origins specify custom dictionaries that browsers use for decompression. Cloudflare says it plans to contribute to that proposal and publish its research soon.
