Transfer-Encoding
Streaming a response before the total body size is known requires chunked framing. The Transfer-Encoding request and response header specifies the hop-by-hop encoding applied to the message body for safe transfer between nodes.
Usage
The Transfer-Encoding header is a hop-by-hop header describing how the message body is encoded for the current connection segment. Each intermediary (proxy, gateway) decodes the transfer encoding, processes the message, and re-encodes before forwarding to the next node.
The most common value is chunked, which allows a
server to start Streaming a response before
knowing the total Content-Length.
The server breaks the body into chunks, each prefixed
with a size indicator. A zero-length chunk signals the
end of the message.
Unlike Content-Encoding, which applies end-to-end compression to the resource itself, Transfer-Encoding operates only between two adjacent nodes. A server sending a gzip-compressed resource over a chunked connection uses Content-Encoding for the compression and Transfer-Encoding for the chunking.
When Transfer-Encoding appears in a response to an HTTP HEAD request, the value reflects the encoding the server applies to the body in a corresponding GET response.
Note
Content-Encoding is end-to-end: the resource itself is compressed (e.g., gzip) and every recipient decodes the payload. Transfer-Encoding is hop-by-hop: encoding applied for transport between two adjacent nodes and removed at each hop. A response may carry both headers at once, using Content-Encoding for resource compression and Transfer-Encoding for chunked delivery.
Note
The HTTP Transfer-Encoding header is unrelated to email's Content-Transfer-Encoding, which handles MIME encoding like base64 or quoted-printable for email bodies.
Note
The Transfer-Encoding header is forbidden in HTTP/2 and HTTP/3. These protocols provide their own data framing mechanisms, making transfer-level encoding unnecessary.
Directives
chunked
The chunked directive splits the message body into
a series of chunks. Each chunk starts with the chunk
size in hexadecimal, followed by the chunk data. A
final chunk of size zero terminates the message. The
Trailer header lists any fields appended
after the last chunk.
compress
The compress directive applies Lempel-Ziv-Welch
(LZW) compression. This encoding is rarely used in
modern deployments.
deflate
The deflate directive applies zlib compression
with the deflate algorithm.
gzip
The gzip directive applies Lempel-Ziv coding (LZ77)
with a 32-bit CRC checksum. This is the same
algorithm used by the gzip file format and is widely
supported across HTTP implementations.
Example
A server sends a chunked response. The absence of a Content-Length header indicates the server is streaming the body in pieces.
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
0\r\n
\r\n
Multiple transfer encodings are applied in order. In this response, the body is first gzip-compressed and then chunked for transmission.
Transfer-Encoding: gzip, chunked