Skip to content

Content-Encoding

Description

The Content-Encoding response header indicates what encodings have been applied to the representation of the resource before transfer. This header is primarily used to specify compression algorithms that have been applied to the response body, allowing clients to properly decode the content after receiving it.

Content encoding is a way to reduce the size of transmitted data, improving transfer speeds and reducing bandwidth usage. Common encoding methods include gzip, deflate, and br (Brotli), which can significantly reduce the size of text-based content like HTML, CSS, JavaScript, and JSON.

When a client indicates support for specific encodings using the Accept-Encoding request header, the server can choose to encode the response using one of those encodings and specify the chosen encoding in the Content-Encoding response header.

Syntax

The syntax of the Content-Encoding header follows this structure:

Content-Encoding: <encoding>[, <encoding>]*
  • <encoding>: The encoding format applied to the response body.
  • Multiple encodings can be specified, separated by commas, indicating that multiple encodings have been applied in the order listed.

Common Encoding Values

  • gzip: Content encoded using the Lempel-Ziv coding (LZ77) with a 32-bit CRC.
  • deflate: Content encoded using the zlib format with the deflate compression algorithm.
  • br: Content encoded using the Brotli algorithm.
  • identity: No encoding has been applied (this is typically omitted rather than explicitly specified).
  • compress: Content encoded using the Lempel-Ziv-Welch (LZW) algorithm (rarely used today).

Example Syntax

Content-Encoding: gzip

This example indicates that the response body has been compressed using the gzip algorithm.

Examples

Basic Example

A response with gzip encoding:

HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 16:00:00 GMT
Content-Type: text/html
Content-Encoding: gzip
Content-Length: 1234

[...gzipped content...]

Multiple Encodings Example

A response with multiple encodings applied in sequence:

HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 16:10:30 GMT
Content-Type: application/javascript
Content-Encoding: gzip, br
Content-Length: 987

[...content encoded with both gzip and br...]

In this example, the content was first compressed with gzip, and then with Brotli (br). The client should apply the decompression algorithms in the reverse order (first br, then gzip).

API Response Example

A JSON API response with Brotli compression:

HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 16:20:45 GMT
Content-Type: application/json
Content-Encoding: br
Content-Length: 456
Vary: Accept-Encoding

[...brotli compressed JSON content...]

Note the Vary: Accept-Encoding header, which is commonly included with compressed responses to indicate that the response may vary based on the client's supported encodings.

Summary

The Content-Encoding response header is an essential component of HTTP content negotiation that enables efficient data transfer through compression. By specifying the encoding method used, this header ensures that clients can correctly decode and process the response body. Proper use of content encoding can significantly improve web performance by reducing the amount of data transferred over the network, leading to faster page loads and reduced bandwidth consumption.