HTTP 206 Partial Content — What It Means & How to Debug

HTTP 206 Partial Content is sent when a client requests only part of a resource using Range headers — essential for video streaming, resume downloads, and chunked data.

What It Means

The HTTP 206 Partial Content status code indicates the server is fulfilling a partial GET request. The client included a Range header specifying which byte ranges it wants, and the server responds with only those bytes. This enables efficient large-file delivery without transferring the entire resource.

The response includes a Content-Range header describing which bytes are included (e.g., bytes 0-1023/8192), and the body contains only the requested range. The Content-Type remains the same as the full resource, and the response may include multiple ranges in a multipart body using Content-Type: multipart/byteranges.

This mechanism is the backbone of modern media delivery. Video players, PDF viewers, and download managers all rely on 206 to stream content in chunks, seek to arbitrary positions, and resume interrupted downloads.

When It’s Sent

• Video streaming — a browser requests a specific byte range for the next chunk of a video file
• Resume interrupted downloads — a download manager resumes from the last received byte
• PDF viewers — requesting only the rendered pages rather than the entire document
• Audio streaming — skipping to a specific timestamp in a podcast or music file
• Large file transfers — splitting a multi-GB download into parallel chunked requests

Real Example

curl -v -H "Range: bytes=0-1023" https://example.com/video.mp4

Expected response:

> GET /video.mp4 HTTP/1.1
> Host: example.com
> Range: bytes=0-1023
>
< HTTP/1.1 206 Partial Content
< Content-Type: video/mp4
< Content-Range: bytes 0-1023/20971520
< Content-Length: 1024
< Accept-Ranges: bytes
<
* 1024 bytes of binary video data

The Content-Range header shows the range returned (0-1023) and the total file size (20971520 bytes). The Accept-Ranges: bytes header signals that the server supports range requests.

How to Debug

Client-Side

1. Verify the Range header — check that the range syntax is correct: Range: bytes=<start>-<end>
2. Check the response code — if you get 200 OK instead of 206, the server ignored your range request
3. Validate Content-Range — ensure the returned range matches what you requested
4. Test without Range first — confirm the resource exists with a regular GET

Server-Side

1. Enable Range support — not all web frameworks support Range headers by default
2. Verify Accept-Ranges header — the response should include Accept-Ranges: bytes
3. Check for compression conflict — if the server compresses responses (gzip), range requests may not work
4. Test with multiple ranges — some servers only handle single-range requests

curl

# Request the first 1 KB
curl -s -H "Range: bytes=0-1023" -o /dev/null -w "%{http_code}" \
  https://example.com/file.bin

# Download in two chunks simultaneously
curl -H "Range: bytes=0-499" -o chunk1.bin https://example.com/file.bin &
curl -H "Range: bytes=500-999" -o chunk2.bin https://example.com/file.bin &

Postman

Add a Range header with value bytes=0-1023 in the Headers tab. Send the request — the status should show 206 Partial Content. Check the Content-Range and Accept-Ranges headers in the response.

Common Causes

FAQ

Related Codes

• HTTP 200 OK — returned when the server ignores Range headers
• HTTP 304 Not Modified — conditional requests for cached range content
• HTTP 416 Range Not Satisfiable — when the requested range is outside the file boundaries
• HTTP 500 Internal Server Error — when the server fails to process the range request