HTTP 206 Partial Content – Free, Online, Private

What HTTP 206 means

206 is the success response to a Range request. The body is the requested slice, and Content-Range says which bytes and how large the whole resource is. Clients use it for downloads that resume and for media playback. A 200 to a Range request means the server ignored the range and sent the entire representation, which is allowed and which clients must handle.

206 Partial Content belongs to the 2xx successful class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 206

When you see HTTP 206 Partial Content, stop on that exact status line. 206 Partial Content returns a byte range of the resource, not the whole file. The trace that usually produces it: A video player asked for a byte range and the file server honored it. The 2xx successful class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 206 when you are honoring a Range header and the range was satisfiable. Include Content-Range and Content-Length for the slice you sent. If the range is invalid, return 416. If you refuse to do ranges, ignore Range and return 200 with the full body. Do not return 206 with the full body.

How to fix HTTP 206

To fix HTTP 206, change the condition that made the server choose Partial Content. Check Content-Range before appending bytes to a file. If you receive 200 instead, replace the local copy. Do not append a full body to a partial file. Retry the same range if the connection drops. Do not restart from byte 0 unless the local partial file is discarded. The method is GET, so a retry is safe. If the log line is a different code, leave this page. The mix-up people make with 206 is this one: 416 means the range was not satisfiable. 200 means you got the whole resource. 206 is only the slice.

• A download resumed after a dropped connection using the bytes it already had.
• Content-Range was missing or described the wrong slice, so the client concatenated garbage.
• A cache stored a 206 and later returned it as if it were the full representation.

An access log that only stores 206 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

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

Content-Range says the body is the first 1024 bytes of a 4096-byte resource. The player will ask for the next range. Accept-Ranges: bytes on the full 200 tells clients they may try. Without it, some clients will not send Range.

What the client should do

Check Content-Range before appending bytes to a file. If you receive 200 instead, replace the local copy. Do not append a full body to a partial file.

Caches must not serve a stored 206 as the full resource. Range caching is its own set of rules. If you are unsure, do not cache 206.

Retry the same range if the connection drops. Do not restart from byte 0 unless the local partial file is discarded. The method is GET, so a retry is safe.

Codes people confuse with HTTP 206

416 means the range was not satisfiable. 200 means you got the whole resource. 206 is only the slice.