Content-Encoding

Content-Encoding is a response header that tells the client which compression algorithm was applied to the response body. Common values are gzip, br (Brotli), and the newer zstd (Zstandard). The client must decompress the body using the specified algorithm before it can use the content. Browsers handle this transparently, so you never see compressed gibberish on screen.

The negotiation works through a request/response dance. The client sends an Accept-Encoding header listing the algorithms it supports, like Accept-Encoding: gzip, br, zstd. The server picks the best one it can provide and sets Content-Encoding accordingly. If the server does not support any of the requested encodings, it sends the response uncompressed with no Content-Encoding header.

This must always be paired with Vary: Accept-Encoding in the response. Without it, a cache might store the gzip version and serve it to a client that sent Accept-Encoding: br, or worse, to a client that does not support compression at all. CDNs often handle compression at the edge, either compressing on the fly or storing pre-compressed variants of popular assets to avoid burning CPU on every request.

// Client request
GET /bundle.js HTTP/1.1
Host: cdn.example.com
Accept-Encoding: gzip, br, zstd

// Server response (Brotli chosen)
HTTP/1.1 200 OK
Content-Encoding: br
Content-Type: application/javascript
Content-Length: 14829
Vary: Accept-Encoding
Cache-Control: max-age=31536000