Accept-Encoding
The HTTP Accept-Encoding header is primarily a request header listing the content encodings a client supports, typically Compression algorithms. The specification also defines a limited response usage where a server lists accepted encodings for content coding in future requests to the same resource.
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.
Note
In some cases, even where the client and server support the same encoding methods, there is no manipulation of the original resource before sending. This occurs in situations where the identity value of the resource is also acceptable. One common example is when the data is already compressed, and applying a subsequent Compression algorithm will not further reduce the size. This happens with pre-compressed image files, such as JPEG. Another situation is where the server is heavily loaded and unable to spare the resources required to manipulate the data pre-transmission.
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.
SEO impact
Google's crawlers and fetchers support gzip,
deflate, and Brotli (br) content encodings. Each
Google user agent advertises the supported
encodings in the Accept-Encoding header of
every request, typically as
Accept-Encoding: gzip, deflate, br. Serving
compressed responses to Googlebot reduces
bandwidth and crawl time. Bingbot sends
Accept-Encoding: gzip, deflate.
Directives
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: www.example.re
Accept-Encoding: gzip
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *
Request (variation #2)
GET / HTTP/1.1
Host: www.example.re
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
Takeaway
The HTTP Accept-Encoding header is primarily a request header used by clients to inform the server which encoding methods they support. The server selects a supported algorithm and signals the choice through Content-Encoding. A server sends Accept-Encoding in a response only to advertise accepted encodings for content coded in future requests, a pattern rarely seen in practice.
