HTTP 416 Range Not Satisfiable – Free, Online, Private

What HTTP 416 means

416 is the failure paired with 206. The client asked for a range the server cannot return, often a start past the end of the file. The response should include Content-Range: bytes */length so the client learns how big the resource is. A download client then knows its local offset is wrong.

416 Range Not Satisfiable belongs to the 4xx client error 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 416

When you see HTTP 416 Range Not Satisfiable, stop on that exact status line. 416 Range Not Satisfiable means the Range header asked for bytes the resource does not have. The trace that usually produces it: A download resumed past the end of a file that was replaced by a shorter one. The 4xx client error 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 416 when a Range is syntactically understood and unsatisfiable. If you do not support ranges, ignore Range and return 200. If the header is garbage, 400 is reasonable. Do not return 206 with an empty body for an impossible range.

How to fix HTTP 416

To fix HTTP 416, change the condition that made the server choose Range Not Satisfiable. Read Content-Range. If your offset is past the end, start over. Do not append more bytes to a file that no longer matches the server. Retry with a satisfiable range, or with no Range header. Retrying the same Range will fail. If the log line is a different code, leave this page. The mix-up people make with 416 is this one: 206 is a range that worked. 200 is the whole resource. 400 is a Range header you could not parse. 416 is a parsed range the resource cannot satisfy.

• The client used a suffix range the server does not implement.
• Content-Range on the 416 used the wrong length, so the client computed a new bad offset.
• A range on a POST was rejected with 416 even though ranges apply to GET.

An access log that only stores 416 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 416 Range Not SatisfiableHTTP/1.1 416 Range Not Satisfiable
Content-Range: bytes */4096

The star means 'no range was returned'. 4096 is the current length. The client should discard a local partial file that is longer than 4096 or that was based on a different version, then GET from the start or from a legal offset. An ETag mismatch is a reason to start over even if the length looks right.

What the client should do

Read Content-Range. If your offset is past the end, start over. Do not append more bytes to a file that no longer matches the server.

Do not cache 416 as the resource. The full representation is a 200.

Retry with a satisfiable range, or with no Range header. Retrying the same Range will fail.

Codes people confuse with HTTP 416

206 is a range that worked. 200 is the whole resource. 400 is a Range header you could not parse. 416 is a parsed range the resource cannot satisfy.