How does Cloudflare compress content?
Cloudflare compresses content in two ways: between Cloudflare and your website visitors and between Cloudflare and your origin server.
Compression between Cloudflare and website visitors
In addition to Cloudflare’s default caching behavior and auto minification (deprecated) of CSS, JavaScript, and HTML content, Cloudflare supports Gzip and Brotli compression when delivering content to website visitors.
If supported by visitors’ web browsers, Cloudflare will return Gzip or Brotli-encoded responses for the following content types:
text/htmltext/richtexttext/plaintext/csstext/x-scripttext/x-componenttext/x-java-sourcetext/x-markdownapplication/javascriptapplication/x-javascripttext/javascripttext/jsimage/x-iconimage/vnd.microsoft.iconapplication/x-perlapplication/x-httpd-cgitext/xmlapplication/xmlapplication/rss+xmlapplication/vnd.api+jsonapplication/x-protobufapplication/jsonmultipart/bagmultipart/mixedapplication/xhtml+xmlfont/ttffont/otffont/x-woffimage/svg+xmlapplication/vnd.ms-fontobjectapplication/ttfapplication/x-ttfapplication/otfapplication/x-otfapplication/truetypeapplication/opentypeapplication/x-opentypeapplication/font-woffapplication/eotapplication/fontapplication/font-sfntapplication/wasmapplication/javascript-binastapplication/manifest+jsonapplication/ld+jsonapplication/graphql+jsonapplication/geo+json
Cloudflare’s global network can deliver content to website visitors using Gzip compression, Brotli compression, or no compression, according to the values visitors provide in the Accept-Encoding
request header.
For responses with error status codes, Cloudflare will only compress responses if their error status code is 403
or 404
. For successful response status codes, Cloudflare will only compress responses if their status code is 200
. Responses with other status codes will not be compressed.
Enterprise customers can override Cloudflare’s default compression behavior using Compression Rules.
Content compression from origin servers to the Cloudflare network
When requesting content from your origin server, Cloudflare supports Gzip compression, Brotli compression, or no compression.
If your origin server responds to a Cloudflare request using Gzip/Brotli compression, we will keep the same compression in the response sent to the website visitor if:
- You include a
Content-Encoding
header in your server response mentioning the compression being used (gzip
orbr
). - The visitor browser (or client) supports the compression algorithm.
- You do not enable Cloudflare features that change the response content (refer to Notes about end-to-end compression for details).
Cloudflare’s reverse proxy can also convert between compressed formats and uncompressed formats. Cloudflare can receive content from your origin server with Gzip or Brotli compression and serve it to visitors uncompressed (or vice versa), independently of caching.
If you do not want a particular response from your origin to be encoded with Gzip/Brotli when delivered to website visitors, you can disable this by including a cache-control: no-transform
HTTP header in the response from your origin web server.
Notes about end-to-end compression
Even when using the same compression algorithm end to end (between your origin server and Cloudflare, and between the Cloudflare global network and your website visitor), Cloudflare will need to decompress the response and compress it again if you enable any of the following options for the request:
- Email Address Obfuscation
- Rocket Loader
- Server Side Excludes (deprecated)
- Mirage
- HTML Minification (deprecated)
- Automatic HTTPS Rewrites
- Polish
To disable these features for specific URI paths, create a Configuration Rule.
Additionally, Cloudflare Fonts also requires Cloudflare to decompress the response and compress it again, and cannot be disabled through Rules at this time.