Accept-EncodingAccept-Encoding tells the server which content compression schemes the client can decode. The server picks one, compresses the body, and reports the scheme actually used in the Content-Encoding header.
It lists tokens like gzip, br (Brotli), deflate, and zstd, and, like Accept, can tune preference with `;q=` weights. `identity` means no compression, and `identity;q=0` refuses an uncompressed response. The server chooses a scheme it supports that the client accepts; if none, it may send uncompressed or reply 406.
Compression yields large bandwidth savings on text (HTML, CSS, JS, JSON) but almost nothing on already-compressed resources (JPEG, PNG, mp4, zip). Because the response varies by Accept-Encoding, you must send `Vary: Accept-Encoding` for cache correctness.
This header governs end-to-end content coding. Hop-by-hop transfer compression is handled by Transfer-Encoding and its companion TE header, which is a distinct concept.
Accept-Encoding: <coding>[;q=<weight>][, ...]e.g. Accept-Encoding: gzip, deflate, br
gzip | The most widely used LZ77-based compression (RFC 1952). |
br | Brotli compression, higher ratio than gzip and preferred on the web. |
deflate | zlib/DEFLATE compression; less preferred than gzip due to implementation confusion. |
zstd | Zstandard compression; fast with good ratio, support is growing. |
identity | No compression. `identity;q=0` refuses an uncompressed response. |