Accept-Encoding

Usage

The HTTP Accept-Encoding request header is part of the content negotiation process and specifies which encoding methods are supported by the client. The server will choose one of the available methods and then inform the client of the selection by including the Content-Encoding header in the HTTP response.

Multiple encodings are specified using separate HTTP Accept-Encoding headers, or instead, by using a comma-delimited list. The q-factor is also included to indicate a preference or priority.

gzip

The gzip directive indicates the client supports GNU zip compression. This is the most widely supported encoding on the web.

deflate

The deflate directive indicates the client supports zlib compression. Despite the name, this uses zlib wrapping around the raw DEFLATE compressed data.

br

The br directive indicates the client supports Brotli compression. Brotli typically achieves better compression ratios than gzip for text-based content.

zstd

The zstd directive indicates the client supports Zstandard compression. Zstandard offers high compression ratios with fast decompression speeds.

identity

The identity directive indicates no encoding is applied. This value is always considered acceptable unless explicitly excluded with identity;q=0.

* (wildcard)

The * wildcard matches any encoding not already listed in the header. If no Accept-Encoding header is present, the server treats the request as if * were specified.

;q= (quality values)

The ;q= parameter assigns a weight between 0 and 1 to each encoding, where 1 is the highest priority and 0 means “not acceptable.” When omitted, the default quality value is 1. The server uses these weights to select the preferred encoding.

Example

In this example, the client requests the server to use one of several encoding methods. In the first variation, each of the options is given equal priority. In the second variation, the q-value directive is used to assign weight to the encoding priority. The server responds with the list of encodings applied, ordered in the way they were processed.

Request (variation #1)

GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *

Request (variation #2)

GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, br;q=1.0, identity;q=0.5, *;q=0.25

Response

HTTP/1.1 200 OK
Content-Encoding: gzip, br

Troubleshooting

Compression not applied despite Accept-Encoding. Some reverse proxies strip Accept-Encoding from the request before forwarding. In nginx, proxy_set_header Accept-Encoding $http_accept_encoding preserves the original value. Verify with curl -H “Accept-Encoding: gzip” -I.

Unexpected encoding selected. Quality values (q-factors) control preference order. A request with Accept-Encoding: gzip;q=0.5, br;q=1.0 prefers Brotli. Omitting q-values assigns equal weight, and the server chooses freely.

CORS preflight missing Accept-Encoding. The Accept-Encoding header is safelisted for CORS and does not trigger preflight. If compression stops working on cross-origin requests, check that the server applies compression regardless of the Origin header.

CDN serving uncompressed responses. Some CDNs compress only when the origin sends an uncompressed response with an appropriate Content-Type. Verify the origin responds with Vary: Accept-Encoding so the CDN caches compressed and uncompressed variants separately.

Identity encoding rejected. Sending Accept-Encoding: identity;q=0 tells the server the client cannot accept uncompressed responses. If no supported encoding is available, the server returns 406 Not Acceptable. Avoid setting identity to q=0 unless all listed encodings are guaranteed available.