Overview

Content-Encoding states the compression/transformation actually applied to the body. The receiver reads it, restores (decodes) the body to its original form, then interprets it per Content-Type.

Details

It is most often used on responses: the server honors the client's Accept-Encoding preference, compresses with gzip, br, etc., and reports the coding used here. If several codings are applied in sequence, they are listed in the order applied (the receiver decodes in reverse). This is an end-to-end transformation preserved all the way to the final recipient.

Crucially, Content-Length refers to the byte count after encoding, so the Content-Length of a Content-Encoding-compressed response is the compressed size. Content-Type, by contrast, describes the type of the original content once decompressed.

Unlike Transfer-Encoding, which is hop-by-hop and stripped per connection, Content-Encoding is treated as part of the resource representation itself. Thus ETags and caches key on the encoded representation, and `Vary: Accept-Encoding` is required.

Syntax

Content-Encoding: <coding>[, <coding>]*

e.g. Content-Encoding: gzip

Directives / values

Notes

• Re-gzipping already-compressed formats (JPEG, PNG, zip, mp4) can actually increase size.
• You can also apply Content-Encoding to a request body, but the server may reject it with 415 if unsupported.
• Combined with HTTPS, compression can open BREACH attack surface, so handle secret values carefully.
• Don't confuse it with Transfer-Encoding (hop-by-hop) — their purpose and cache treatment differ.

Related headers

Related status codes

Specification