Content-Encoding
response headercontent
Says how the body was compressed — gzip, Brotli or zstd — so the client can decompress it.
Servers compress text responses — HTML, CSS, JavaScript, JSON — to cut transfer size by 60–80%. The client lists what it supports in Accept-Encoding, and the server labels its choice with Content-Encoding. Browsers decompress transparently.
Syntax
Content-Encoding: gzip | br | zstd | deflate
Defined in RFC 9110 §8.4 — Content-Encoding.
Values
| br | Brotli — smaller than gzip for text, supported by every current browser |
|---|---|
| gzip | the universal fallback |
| zstd | Zstandard — fast, newer browser support |
| deflate | rarely used; inconsistent implementations |
Examples
Content-Encoding: br
a Brotli-compressed response
Content-Encoding: gzip
a gzip-compressed response
Good to know
- Don't compress images, video or zip files — they're already compressed.
- Compressed responses should carry
Vary: Accept-Encoding; servers add it automatically. - A doubly compressed body, or a header that doesn't match the bytes, shows up as garbled output or
ERR_CONTENT_DECODING_FAILED.
Who sets Content-Encoding
Web servers and CDNs pick and apply the encoding automatically (nginx gzip on;, Vercel and Cloudflare by default). Check what you get with curl -sI -H "Accept-Encoding: br, gzip" https://example.com/ | grep -i content-encoding.
Check it
Fetch only the response headers and filter for Content-Encoding. In the browser, it's under Response Headers in DevTools → Network.
curl -sI https://example.com/ | grep -i '^content-encoding:'
To compare response headers across many URLs at once, use the HTTP Status Checker.
Frequently asked questions
Why doesn't curl show Content-Encoding?
curl doesn't ask for compression unless you send Accept-Encoding (or use --compressed), so servers reply uncompressed.