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

Content-Encoding is an end-to-end property of the representation: the body is compressed and stays compressed until the client decodes it. Transfer-Encoding is a hop-by-hop framing applied for one connection — chunked is its main use. Use Content-Encoding for compression in practice.

What does Transfer-Encoding: chunked do?

It breaks the body into size-prefixed chunks so the server can stream a response of unknown length without a Content-Length header. The transfer ends with a zero-length chunk, optionally followed by trailer headers.

Is gzip used in Transfer-Encoding or Content-Encoding?

Almost always Content-Encoding. Although the spec allows Transfer-Encoding: gzip, real-world compression is advertised via Accept-Encoding and applied as Content-Encoding, because it is an end-to-end property that caches must preserve.

Why does HTTP/2 forbid chunked?

HTTP/2 and HTTP/3 have their own binary framing layer, so the chunked transfer-coding is not used and the Transfer-Encoding header is prohibited. Message length is determined by the framing itself.

Does this tool send any request?

No. It is a static, browser-rendered reference. It performs no network calls and stores nothing.

Transfer-Encoding Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Framing versus compression — two headers people conflate

Transfer-Encoding and Content-Encoding look similar but mean different things. One frames the message for a single connection hop (chunked); the other compresses the representation end-to-end (gzip, br). Confusing them leads to double-compression bugs and caches serving undecodable bodies. This reference sorts every coding value into the right layer.

How it works

Content-Encoding is end-to-end. The body is compressed (gzip, br, deflate, zstd) and a cache stores it that way; the client decodes it. It is negotiated via Accept-Encoding and recorded in Vary.
Transfer-Encoding is hop-by-hop, applied for one connection then stripped by the next. Its dominant value is chunked, which streams a body of unknown length as size-prefixed chunks ending in a zero-length chunk:

Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
0\r\n
\r\n

Multiple codings are applied left-to-right and decoded right-to-left, with chunked always last in a Transfer-Encoding list. In HTTP/2 and HTTP/3 the binary framing replaces all of this, so Transfer-Encoding is prohibited there.

Tips and notes

Compress with Content-Encoding, not Transfer-Encoding, in practice.
Never set both a Content-Length and Transfer-Encoding: chunked.
Don’t double-compress: a br body served as gzip Content-Encoding is corrupt.
Trailers ride after the final chunk; advertise them with the TE: trailers request header.