What is the difference between the HTTP Content-Encoding and Transfer-Encoding headers?

## Two different layers HTTP separates *what the resource is* from *how this particular message is put on this particular connection*. - **Content-Encoding** answers: has the representation been transformed, and how do I get the payload back? It belongs to the resource. - **Transfer-Encoding** answers: how are the bytes of this message framed on this hop? It belongs to the connection. Everything else follows from that split. ## End-to-end versus hop-by-hop `Content-Encoding` is **end-to-end**. A gzipped response passes through proxies and caches still gzipped; the cache stores the compressed octets; only the user agent decodes. That is why `Vary: Accept-Encoding` matters — the stored entity really is a different byte sequence per coding — and why `ETag` must differ between the gzip and Brotli representations of the same resource. Get that wrong and a conditional request can splice a gzip validator onto a Brotli body. `Transfer-Encoding` is **hop-by-hop**. A proxy is entitled to receive a chunked message and forward it with `Content-Length`, or the reverse. It is never cached, never part of the entity, and never seen by application code that reads a parsed body. ## Chunked: the one transfer coding that matters ``` HTTP/1.1 200 OK Content-Type: application/json Transfer-Encoding: chunked 1a\r\n{"status":"processing"}\r\n\r\n 0\r\n\r\n ``` Chunked framing lets a server start sending before it knows the total length — streaming, server-generated pages, long-running exports — while keeping the connection reusable. Before HTTP/1.1, the only way to signal "body ends here" without a length was to close the connection. Chunked composes with `Content-Encoding`: a streamed, gzipped JSON response carries `Content-Encoding: gzip` **and** `Transfer-Encoding: chunked`. They are not alternatives; they answer different questions. ## Why compression as a transfer coding never happened On paper, `Transfer-Encoding: gzip` with `TE: gzip` is the architecturally cleaner way to compress *for transport* — it is per-hop, so a cache stores the entity once in identity form and each hop compresses as appropriate, and no `Vary` gymnastics are needed. In reality almost nothing implements it: intermediaries mishandled `Transfer-Encoding` values other than `chunked` badly enough that the ecosystem standardised on `Content-Encoding` for compression. Knowing *why* the theoretically nicer option lost is the senior-level part of this answer. ## Content-Length interactions and request smuggling A message must not carry both `Content-Length` and `Transfer-Encoding: chunked`. If it does, different implementations disagree about which wins — a front-end proxy may honour one and the back-end the other, letting an attacker hide a second request inside the body. That is **HTTP request smuggling** (CL.TE / TE.CL). RFC 9112 therefore requires that such a message be rejected, and hardened front-ends normalise or refuse messages with conflicting framing. When `Content-Encoding` is present and `Content-Length` is used, the length is that of the **encoded** bytes — the octets actually on the wire. ## HTTP/2 and HTTP/3 HTTP/2 and HTTP/3 abolish `Transfer-Encoding` entirely. Framing is a job of the binary protocol: DATA frames carry the body and the stream ends when END_STREAM is set, so there is nothing for a chunked coding to do. Sending `Transfer-Encoding` in HTTP/2 is a protocol error, and `Connection`-style hop-by-hop headers are likewise banned. Bodies of unknown length are simply streams that end. `Content-Encoding`, being about the representation rather than the connection, is unaffected and works identically in HTTP/1.1, /2 and /3. ## A quick diagnostic table | | Content-Encoding | Transfer-Encoding | |---|---|---| | Scope | end-to-end (representation) | hop-by-hop (connection) | | Negotiated by | `Accept-Encoding` | `TE` | | Typical value | `gzip`, `br`, `zstd` | `chunked` | | Cached as-is | yes | no, stripped | | Affects ETag | yes | no | | In HTTP/2 & /3 | yes | forbidden | ## How to spot the confusion in an interview Candidates often say chunked "compresses the response in pieces", or that gzip is a transfer encoding. The clean framing to give is: *Content-Encoding changes what the bytes are; Transfer-Encoding changes how the bytes are delimited on one hop* — and in modern HTTP versions only the first still exists.