HTTP headers · Request
Accept-Encoding
Accept-Encoding lists the compression formats the client can decode.
Key facts
| Type | Request |
|---|---|
| Common codings | gzip, br, zstd, deflate |
| Identity | No compression, acceptable by default |
| Refusal | <code>identity;q=0</code> |
| Response | <code>Content-Encoding</code> names the coding |
| Caching | Include <code>Vary: Accept-Encoding</code> |
| Standard | RFC 9110 §12.5.3 |
Compression negotiation
The client advertises codings it can decode. The server compresses the body, sets Content-Encoding to the chosen coding, and keeps Content-Type describing the original data. The two headers are independent: a JSON body can be gzip-compressed and still be JSON.
identity means no transformation and is acceptable unless the client sets identity;q=0. Brotli often beats gzip for text, but compression costs CPU and is pointless for already-compressed images or video.
Caching and correctness
Responses that vary by encoding need Vary: Accept-Encoding, or a cache can hand a gzip body to a client that asked for identity. Some CDNs store each encoding separately; others normalize and recompress at the edge.
Never compress a response that is already compressed. For ordinary web pages, the trade-off is bandwidth versus CPU; for secrets in interactive protocols, compression can also leak information through length.
Frequently asked questions
What happens if the client cannot decode the response?
It must fail rather than guess. A server should only choose a coding the client listed, or identity.
Is Content-Length the compressed size?
Yes, when compression is applied. It measures the bytes on the wire.