We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Web Content Delivery
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Web Content Delivery
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A developer opened Chrome DevTools and saw the same API endpoint returning different Content-Encoding values for different requests: br, gzip, and sometimes no encoding at all. This was not a bug. It was content negotiation working exactly as designed.
Content encoding is the HTTP protocol layer that makes compression transparent. The application sends uncompressed bytes. The server (or reverse ) compresses them. The browser decompresses them. Neither the application code writing the response nor the JavaScript code reading it ever sees compressed bytes. The entire compression/decompression round trip happens at the HTTP transport layer.
Understanding content encoding matters when you are debugging why a response is larger than expected, configuring a , or diagnosing why a cache is serving corrupted responses. The Vary header alone causes more caching bugs than almost any other HTTP mechanism.
content encoding follows a strict request/response negotiation:
1. Client advertises capabilities:
GET /api/products HTTP/2
Accept-Encoding: br, gzip, deflate
The Accept-Encoding header lists every compression algorithm the client can decompress, in no particular order. The client says "I understand Brotli, gzip, and deflate. Send me whichever you prefer."
2. Server picks the best match:
The server (or reverse ) examines the Accept-Encoding header and selects the algorithm it can produce that yields the best compression. Typical priority: Brotli > gzip > identity.
3. Server tags the response:
HTTP/2 200 OK
Content-Encoding: br
Content-Type: application/json
Vary: Accept-Encoding
Content-Length: 12847
Content-Encoding: br tells the client the response body is Brotli-compressed. The client decompresses before passing data to JavaScript. Content-Length reflects the compressed size, not the original size.
4. The identity encoding:
When the server cannot or should not compress (binary content, tiny responses), it sends no Content-Encoding header. The implicit encoding is identity, meaning "no transformation applied." Some servers explicitly send Content-Encoding: identity, but most omit the header entirely.