content
Content-Encoding
Indicates that the body has been transformed with one or more compressions and must be decoded in reverse order to recover the original payload. Negotiated via the client's Accept-Encoding.
Content-Encoding: <coding>[, <coding>...] (gzip, br, deflate, zstd, identity — applied in order)Common directives / values
| Directive | Purpose |
|---|---|
| gzip | Widely supported LZ77+Huffman compression (RFC 1952). |
| br | Brotli — better ratio than gzip on text; broadly supported over HTTPS. |
| deflate | Raw zlib deflate — history of interop bugs; prefer gzip. |
| zstd | Zstandard — very fast, good ratio; growing browser support. |
| identity | No encoding applied — explicit way to opt out. |
Examples
Content-Encoding: gzipStandard gzipped HTML/JSON/JS response.
Content-Encoding: brBrotli-compressed asset for HTTPS clients that advertised 'br' in Accept-Encoding.
Content-Encoding: gzip\nVary: Accept-EncodingAlways Vary on Accept-Encoding when serving compressed variants to keep caches honest.
Content-Encoding: identityExplicitly uncompressed — useful for Range requests where compression would break offsets.
Gotcha
Applying two encodings (e.g. gzip and br) yields the header 'Content-Encoding: br, gzip' meaning 'brotli-then-gzip'; forgetting the order breaks decoding. Never gzip content twice by accident (Nginx + upstream) — clients decompress once and see garbage.
Related headers
Accept-Encoding
Client advertisement of which content codings it can decode, letting the server compress the response accordingly. Absence means 'identity only'; an explicit identity;q=0 forbids uncompressed responses.
Content-Type
Declares the media type of the body in both requests and responses, and often carries additional parameters like charset or boundary. Governs how the recipient parses or renders the payload.
Content-Length
Number of octets in the message body, letting the recipient know exactly where the message ends. Required for most requests with bodies unless Transfer-Encoding: chunked is used.
Vary
Tells caches which request headers were used for content negotiation, so they know to store and serve separate variants keyed by those headers. Missing or wrong Vary causes users to see cached content meant for someone else (wrong language, encoding, or device).
Content-Disposition
In responses, controls whether the browser renders the body inline or offers it as a download, and suggests a filename. In multipart/form-data request parts, names the form field and optionally the upload filename.