Accept Encoding

The HTTP Accept-Encoding request and response headers specify the content encoding, typically a compression algorithm, that the sender can interpret. In requests, the server employs content negotiation to select an encoding proposal from the client and informs the client of this selection through the Content-Encoding response header. In responses, it provides details about which content encodings the server supports, allowing the client to use the same encoding in subsequent requests to the resource. For example, if a request uses an unsupported encoding, the server responds with 415 Unsupported Media Type. In such cases, Accept-Encoding can be involved in error responses. Even when both the client and server support the same compression algorithms, the server may opt not to compress the response body if the identity encoding is also acceptable. This typically occurs in two situations:

1. The data is already compressed, such as in JPEG images or other pre-compressed formats, where additional compression will not reduce size and may increase it.
2. The server is experiencing high load and lacks the resources to perform compression effectively. For example, Microsoft recommends avoiding compression if the server’s CPU utilization exceeds 80%.

Provided that directives like identity;q=0 or *;q=0 do not explicitly prohibit the identity encoding (meaning no encoding), the server should never return a 406 Not Acceptable error.

Header type	Request header, Response header
Forbidden request header	Yes

Syntax

Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: zstd
Accept-Encoding: dcb
Accept-Encoding: dcz
Accept-Encoding: identity
Accept-Encoding: *

// Multiple algorithms, weighted with the quality value syntax:
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5

Directives

gzip

A compression format that uses the Lempel-Ziv coding (LZ77) with a 32-bit CRC.

compress

A compression format that utilizes the Lempel-Ziv-Welch (LZW) algorithm.

deflate

This compression method employs the zlib structure combined with the deflate algorithm for efficient data compression.

br

A compression format that leverages the Brotli algorithm, offering high compression ratios.

zstd

This format uses the Zstandard compression algorithm, designed for fast and efficient compression.

dcb

A format utilizing the Dictionary-Compressed Brotli algorithm. See Compression Dictionary Transport for more details.

Note: This is an experimental feature; behavior may change in future versions.

dcz

A format that adopts the Dictionary-Compressed Zstandard algorithm. Refer to Compression Dictionary Transport for additional information.

Note: Experimental status; future updates may alter functionality.

identity

Indicates the identity function, meaning no modification or compression is applied. This value is always considered acceptable, even if not explicitly specified.

* (wildcard)

Represents any content encoding not explicitly listed. This is the default when no header is present and indicates that no specific preference is expressed. It does not guarantee support for any particular algorithm.

;q=

This parameter assigns a weight indicating preference among content encodings, using a relative quality value.

Examples

Default Accept-Encoding values

Browsers typically send a request header named Accept-Encoding with major compression algorithms they support. An example of such a header is:  

GET /en-US/ HTTP/2
Host: developer.mozilla.org
Accept-Encoding: gzip, deflate, br, zstd

Weighted Accept-Encoding values

The following header demonstrates the client’s preferences for content encodings using quality values between 0 (lowest preference) and 1 (highest preference). Brotli compression has the highest priority with a weight of 1.0</>, meaning it is the client's first choice. This is followed by gzip with a weight of `0.8`, and all other encodings are considered least preferred with a weight of `0.1`.  

Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1

How to Modify Header using Requestly

Requestly is a powerful Chrome extension that allows you to modify HTTP headers, including the Accept-Encoding header. This is especially useful for testing how your application handles content encodings the client will accept during development or debugging. Steps to Modify the Accept-Encoding Header:

1. Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
2. Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
3. Add a new header modification:
   • Under “Action”, select “Add” or “Override”.
   • In the “Header Name” field, enter Accept-Encoding.
   • In the “Header Value” field, enter your desired value (e.g., gzip).
4. Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., https://your-api.com/\*).
5. Save the rule.

Once set up, Requestly will inject the Accept-Encoding: gzip header into all matching requests, allowing you to test how your server responds to different compression schemes such as gzip, br, or deflate.