Spec-Zone.ru › HTTP

Headers: Accept-Encoding

Accept-Encoding header

Baseline Widely available *

This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.

* Some parts of this feature may have varying levels of support.

  • Learn more
  • See full compatibility
>

The HTTP Accept-Encoding request and response header indicates the content encoding (usually a compression algorithm) that the sender can understand. In requests, the server uses content negotiation to select one of the encoding proposals from the client and informs the client of that choice with the Content-Encoding response header. In responses, it provides information about which content encodings the server can understand in messages to the requested resource, so that the encoding can be used in subsequent requests to the resource. For example, Accept-Encoding is included in a 415 Unsupported Media Type response if a request to a resource (e.g., PUT) used an unsupported encoding.

Even if both the client and the server support the same compression algorithms, the server may choose not to compress the body of a response if the identity value is also acceptable. This happens in two common cases:

  1. The data is already compressed, meaning a second round of compression will not reduce the transmitted data size, and may actually increase the size of the content in some cases. This is true for pre-compressed image formats (JPEG, for instance).
  2. The server is overloaded and cannot allocate computing resources to perform the compression. For example, Microsoft recommends not to compress if a server uses more than 80% of its computational power.

As long as the identity;q=0 or *;q=0 directives do not explicitly forbid the identity value that means no encoding, the server must never return a 406 Not Acceptable error.

Note: IANA maintains a list of official content encodings. The bzip and bzip2 encodings are non-standard, but may be used in some cases, particularly for legacy support.

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 uses the Lempel-Ziv-Welch (LZW) algorithm.

deflate

A compression format that uses the zlib structure with the deflate compression algorithm.

br

A compression format that uses the Brotli algorithm.

zstd

A compression format that uses the Zstandard algorithm.

dcb

A format that uses the Dictionary-Compressed Brotli algorithm. See Compression Dictionary Transport.

dcz

A format that uses the Dictionary-Compressed Zstandard algorithm. See Compression Dictionary Transport.

identity

Indicates the identity function (that is, without modification or compression). This value is always considered as acceptable, even if omitted.

* (wildcard)

Matches any content encoding not already listed in the header. This is the default value if the header is not present. This directive does not suggest that any algorithm is supported but indicates that no preference is expressed.

;q= (qvalues weighting)

Any value is placed in an order of preference expressed using a relative quality value called weight.

Examples

>

Default Accept-Encoding values

Browser navigation typically has the following Accept-Encoding request header value:

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

Weighted Accept-Encoding values

The following header shows Accept-Encoding preferences using a quality value between 0 (lowest priority) and 1 (highest-priority). Brotli compression is weighted at 1.0, making br the client's first choice, followed by gzip at 0.8 priority, and then any other content encoding at 0.1:

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

Specifications

Specification
HTTP Semantics>
# field.accept-encoding>

Browser compatibility

Desktop Mobile
Chrome Edge Firefox Opera Safari Chrome Android Firefox for Android Opera Android Safari on IOS Samsung Internet WebView Android WebView on iOS
Accept-Encoding 1 12 1 15 1 18 4 14 1 1.0 4.4 1
br 50 15 44 36
11Unsupported before macOS 10.13 High Sierra.
51 44 41 11 5.0 51 11
dcb 130 130 No 115 No 130 No 86 No 28.0 130 No
dcz 130 130 No 115 No 130 No 86 No 28.0 130 No
zstd 123 123 126 109
26.3Before macOS 26.3 Tahoe, this header value is not sent.
123 126 No 26.3 27.0 123 26.3

See also

  • 415 Unsupported Media Type
  • HTTP content negotiation
  • A header with the result of the content negotiation: Content-Encoding
  • Other similar headers: TE, Accept, Accept-Language
  • Brotli compression
  • GZip compression
  • Zstandard compression
  • Compression Dictionary Transport guide

© 2005–2025 MDN contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Encoding

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API