Content-Encoding HTTP Header — gzip, br, deflate

Content-Encoding: How Compression Works in HTTP

The HTTP protocol uses a negotiation mechanism to determine which compression algorithm to use for each response.

The Negotiation Flow

1. Client sends Accept-Encoding: gzip, deflate, br in the request header
2. Server compresses the response body using a supported algorithm
3. Server responds with Content-Encoding: gzip (or br, deflate)
4. Client decompresses automatically before passing data to JavaScript/rendering

Supported Encodings

Encoding	Header Value	Algorithm	Browser Support
Gzip	gzip	DEFLATE + headers	100%
Deflate	deflate	Raw DEFLATE	100% (rarely used)
Brotli	br	Brotli	97%+
Zstandard	zstd	Zstandard	Growing

Important Headers

# Request (browser → server)
Accept-Encoding: gzip, deflate, br

# Response (server → browser)
Content-Encoding: gzip
Content-Length: 15234
Vary: Accept-Encoding

The Vary: Accept-Encoding header is critical for correct caching. It tells CDNs and proxies to cache separate versions for different encodings.

Content-Length with Compression

When Content-Encoding is set, Content-Length reflects the compressed size. The original size is not transmitted in any header — the client only knows it after decompression.

Common Pitfalls

• Missing Vary header: Causes CDN cache poisoning (serving gzipped content to clients that don’t support it)
• Double compression: Compressing already-compressed content wastes CPU
• Compression on HTTPS: The BREACH attack can exploit compression on HTTPS responses containing secrets. Mitigations include CSRF tokens and not reflecting user input in compressed responses.