206 Partial Content — HTTP Status Code

206 Partial Content means "here is the piece you asked for." Instead of sending a whole file, the server sends only the byte range named in the request. It is how a video player can jump to the middle of a film, and how a download manager resumes a transfer that broke at 80 percent.

What 206 means

Range requests used to live in their own specification, RFC 7233. That material is now part of RFC 9110: range requests are covered in Section 14, and 206 itself in Section 15.3.7. The code means the server is successfully fulfilling a range request by transferring one or more parts of the selected representation.

How the exchange works:

• The client sends a Range header, such as Range: bytes=0-1023 for the first kilobyte.
• The server answers 206 with a Content-Range header, such as Content-Range: bytes 0-1023/48210, which states the range sent and the full size.
• Content-Length on a 206 is the size of this message's body, not of the whole file.

For a single range, the body is just those bytes. For multiple ranges, the server sends a multipart/byteranges body, each part carrying its own Content-Range. The RFC also allows the server to send less than requested, for example to balance load, since the response describes exactly what it holds. Clients must read Content-Range rather than assume they got what they asked for.

A 206 is heuristically cacheable, and pieces can be stitched together safely only when they share the same strong validator, such as an identical ETag. That rule stops a client from mixing bytes from an old and a new version of a file.

When you see it

• Video and audio. HTML5 media players request ranges to start playback quickly and to seek. In the browser's network panel, media files commonly show 206.
• Resumed downloads. Download managers, curl -C - and wget -c ask for the bytes after what they already have.
• Large PDFs. Some PDF viewers fetch only the pages being displayed.
• CDNs and object storage. They serve range requests from cache and pass them to origin when needed.
• Parallel downloaders. Some tools split a big file into ranges and fetch them at once.

Common problems

1. Ranges ignored. If a server or an intermediate proxy ignores Range, the client gets a full 200 instead. Seeking in videos then restarts from the beginning or is not possible at all.
2. Compression in the way. Range offsets apply to the bytes actually sent. Compressing a file on the fly can break or disable range support, which is one reason media files are usually served uncompressed.
3. Changing files. If the file is replaced mid-download, ranges from two versions no longer fit together. Clients should send If-Range with the validator they started with, so the server returns the full new file instead of a mismatched piece.
4. Invalid ranges. A range beyond the end of the file returns 416 Range Not Satisfiable from servers that support ranges.

How to check it

First see whether the server advertises range support:

curl -I https://cdn.example.com/video/intro.mp4

HTTP/2 200
accept-ranges: bytes
content-length: 48210112

Then ask for the first 100 bytes and look at the headers:

curl -s -D - -o /dev/null -r 0-99 https://cdn.example.com/video/intro.mp4

HTTP/2 206
content-range: bytes 0-99/48210112
content-length: 100

If you get 200 here instead, ranges are not supported for that URL, or something in between strips the header.

What it means for uptime monitoring

A monitor will almost never see 206. PingRobot's checker sends a plain GET without a Range header, so a server returns the full resource with 200. If a final 206 did appear, it would count as up, because statuses from 200 to 399 are treated as up.

If a large media or download URL is what you need to watch, point the monitor at it directly: the status decides up or down, and a keyword check only reads the first 512 KB of the body anyway. For a video platform, it is usually more useful to monitor the page or API that lists the media, plus one representative file on the CDN, than to try to fetch the whole file.

Related codes

• 200 OK — the full resource, when no range was asked for or ranges are not supported
• 304 Not Modified — the cached copy is still valid, nothing to send
• 204 No Content — success with no body at all
• 413 Content Too Large — the size problem in the other direction, on uploads

Start monitoring free — 10 monitors, no credit card.