What is Chunked Transfer Encoding?
Understand chunked transfer encoding in HTTP — how servers stream responses of unknown length using size-prefixed chunks.
Expected Interview Answer
Chunked transfer encoding is an HTTP/1.1 mechanism that lets a server stream a response body in a series of independently-sized chunks without knowing the total length in advance, replacing the need for a `Content-Length` header.
Normally a server sets `Content-Length` so the client knows exactly how many bytes to read before the response ends. When the body is generated dynamically or is too large to buffer fully before sending — such as a live log stream or a database export — the server instead sends `Transfer-Encoding: chunked` and writes the body as a sequence of chunks, each prefixed with its own size in hexadecimal followed by the chunk’s bytes, ending with a zero-length chunk that signals the end of the body. This lets the client start processing data as it arrives instead of waiting for the whole response, which is essential for streaming APIs and server-sent responses of unknown size. Chunked encoding cannot be combined with `Content-Length` on the same response, and HTTP/2 replaces it entirely with its own framing since it does not use `Transfer-Encoding` at all.
- Streams responses whose total size is unknown up front
- Lets clients start processing data before the response finishes
- Removes the need to buffer the entire body server-side first
- Standard HTTP/1.1 mechanism, replaced by native framing in HTTP/2
AI Mentor Explanation
Chunked transfer encoding is like a ground announcer relaying the scorecard over the loudspeaker over-by-over instead of waiting until the full innings ends to read out one final total. Each over’s update is announced with its own small summary, so listeners get live information without knowing in advance how many overs the innings will run. A final silent pause signals the innings is truly complete. This is exactly how a chunked HTTP response streams data as size-prefixed pieces without declaring a total length upfront.
Step-by-Step Explanation
Step 1
Header signals chunking
Server sends `Transfer-Encoding: chunked` instead of `Content-Length`.
Step 2
Each chunk is size-prefixed
Every chunk starts with its byte length in hex, followed by the chunk data.
Step 3
Client reads incrementally
The client processes each chunk as it arrives instead of waiting for the full body.
Step 4
Zero-length chunk ends it
A final chunk of size 0 signals the response body is complete.
What Interviewer Expects
- Explains why Content-Length cannot be known in advance in this case
- Describes the size-prefixed chunk format and terminating zero chunk
- Knows chunked and Content-Length are mutually exclusive
- Aware HTTP/2 uses its own framing instead of Transfer-Encoding
Common Mistakes
- Thinking chunked encoding compresses the response (it does not, by itself)
- Confusing it with HTTP range requests (partial content, a different mechanism)
- Assuming it still applies unchanged under HTTP/2
- Forgetting the terminating zero-length chunk is required
Best Answer (HR Friendly)
“Chunked transfer encoding lets a server send a response in small pieces as it becomes ready, instead of waiting to know the total size before sending anything. It is how streaming APIs and live data feeds work — you get data as it is generated, not after everything is finished.”
Code Example
# Request a chunked endpoint and inspect headers
curl -v https://example.com/stream
# Look for:
# < Transfer-Encoding: chunked
# (no Content-Length header present)
# Raw chunk format looks like:
# 7\r\n
# Mozilla\r\n
# 9\r\n
# Developer\r\n
# 0\r\n
# \r\nFollow-up Questions
- Why are Content-Length and Transfer-Encoding: chunked mutually exclusive?
- How does HTTP/2 handle streaming without Transfer-Encoding?
- What is HTTP request smuggling and how does chunked encoding relate to it?
- How do server-sent events (SSE) relate to chunked responses?
MCQ Practice
1. What header signals a chunked HTTP response?
The `Transfer-Encoding: chunked` header signals that the body is sent as a series of sized chunks.
2. What marks the end of a chunked HTTP response body?
A final chunk with a declared size of zero signals the body is complete.
3. Why is chunked encoding useful for dynamically generated responses?
Chunked encoding avoids needing to know the full body size upfront, ideal for streamed or generated content.
Flash Cards
What is chunked transfer encoding? — An HTTP/1.1 mechanism to stream a response as size-prefixed chunks without a known total length.
What header enables it? — `Transfer-Encoding: chunked`, used instead of `Content-Length`.
How does it end? — With a terminating chunk of declared size zero.
HTTP/2 equivalent? — HTTP/2 uses its own native frame-based streaming, not Transfer-Encoding.