206 Partial Content

This is an educational reference page about HTTP 206 Partial Content. The page itself is served as 200 OK so it can be indexed as HTTP documentation.

The server is delivering only part of the resource (byte serving) due to a range header sent by the client. The range header is used by HTTP clients to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.

Specification

Registered in the IANA HTTP Status Code Registry as Partial Content. Defined in RFC 9110, Section 15.3.7.

What it means

HTTP 206 Partial Content means the server is sending only the byte range or ranges requested by the client.

Common causes

A browser requests part of a video, audio file, PDF, or large download.
A client resumes an interrupted download with a Range header.
A CDN or origin supports byte-range requests for seekable media.

How to fix it

Include Content-Range and the correct Content-Length for the returned range.
Return 416 when the requested range cannot be satisfied.
Use 200 OK instead when the server ignores Range and sends the complete representation.

Example response

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/4096
Content-Length: 1024
Content-Type: video/mp4

Developer notes

206 is common for media playback and resumable downloads. Correct range headers matter because clients use them to stitch content together.

Questions

What does HTTP 206 mean?

HTTP 206 means the response contains only part of the requested resource, usually because the client sent a Range header.

Is 206 an error?

No. HTTP 206 is a successful response used for partial downloads, streaming, and byte-range requests.

Header and content rules

What RFC 9110 says about a 206 response, quoted from the RFC.

MUST (server; Date, Cache-Control, ETag, Expires, Content-Location, Vary): Send those fields, in addition to the part-specific fields below. When: Each field that a 200 response to the same request would have sent. Table row
A server that generates a 206 response MUST generate the following header fields, in addition to those required in the subsections below, if the field would have been sent in a 200 (OK) response to the same request: Date, Cache-Control, ETag, Expires, Content-Location, and Vary. RFC 9110 §15.3.7
SHOULD NOT (sender; representation header fields): Do not send representation header fields beyond the required ones; the client already has them. When: The request had If-Range. Table row
A sender that generates a 206 response to a request with an If-Range header field SHOULD NOT generate other representation header fields beyond those required because the client already has a prior response containing those header fields. RFC 9110 §15.3.7
MUST (sender; representation header fields): Send every representation header field that a 200 response would have sent. When: The request had no If-Range. Table row
Otherwise, a sender MUST generate all of the representation header fields that would have been sent in a 200 (OK) response to the same request. RFC 9110 §15.3.7
MUST (server; Content-Range, content): Send Content-Range for the enclosed range, with that range as the content. When: One part is sent. Table row
If a single part is being transferred, the server generating the 206 response MUST generate a Content-Range header field, describing what range of the selected representation is enclosed, and a content consisting of the range. RFC 9110 §15.3.7.1
MUST (server; Content-Type, content): Send multipart/byteranges content and a Content-Type of multipart/byteranges with its boundary parameter. When: Multiple parts are sent. Table row
If multiple parts are being transferred, the server generating the 206 response MUST generate "multipart/byteranges" content, as defined in Section 14.6, and a Content-Type header field containing the "multipart/byteranges" media type and its required boundary parameter. RFC 9110 §15.3.7.2
MUST NOT (server; Content-Range): Do not put Content-Range in the response header section. Each part carries its own. When: Multiple parts are sent. Table row
To avoid confusion with single-part responses, a server MUST NOT generate a Content-Range header field in the HTTP header section of a multiple part response (this field will be sent in each part instead). RFC 9110 §15.3.7.2
MUST (server; Content-Range): Send Content-Range in the header area of each body part. When: Multiple parts are sent. Table row
Within the header area of each body part in the multipart content, the server MUST generate a Content-Range header field corresponding to the range being enclosed in that body part. RFC 9110 §15.3.7.2
SHOULD (server; Content-Type): Send that same Content-Type in the header area of each body part. When: Multiple parts are sent, and a 200 response would have had Content-Type. Table row
If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type header field in the header area of each body part. RFC 9110 §15.3.7.2
SHOULD (server; content): Send the parts in the order the ranges appeared in the Range header, leaving out unsatisfiable or coalesced ranges. When: Multiple parts are sent. Table row
A server that generates a multipart response SHOULD send the parts in the same order that the corresponding range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges. RFC 9110 §15.3.7.2
MAY (server; content): Coalesce ranges that overlap or are separated by a gap smaller than the multipart overhead. When: Multiple ranges were requested. Table row
When multiple ranges are requested, a server MAY coalesce any of the ranges that overlap, or that are separated by a gap that is smaller than the overhead of sending multiple parts, regardless of the order in which the corresponding range-spec appeared in the received Range header field. RFC 9110 §15.3.7.2
MUST NOT (server; content): Do not send a multipart response. When: The request asked for one range. Table row
A server MUST NOT generate a multipart response to a request for a single range, since a client that does not request multiple parts might not support multipart responses. RFC 9110 §15.3.7.2
MAY (server; content): Send a multipart/byteranges response with a single body part. When: Multiple ranges were requested, but only one was satisfiable or one remained after coalescing. Table row
However, a server MAY generate a "multipart/byteranges" response with only a single body part if multiple ranges were requested and only one range was found to be satisfiable or only one range remained after coalescing. RFC 9110 §15.3.7.2
MUST (client; Content-Type, Content-Range): Read Content-Type and Content-Range to see which parts arrived and whether more requests are needed. Table row
A client MUST inspect a 206 response's Content-Type and Content-Range field(s) to determine what parts are enclosed and whether additional requests are needed. RFC 9110 §15.3.7

The same rules are in the response obligations table and its JSON.