HTTP 416 Range Not Satisfiable explained

What 416 means

HTTP 416 Range Not Satisfiable is the status a server returns when a client asks for a byte range of a resource that does not overlap the resource's actual size. Range requests are what let browsers and download managers resume an interrupted file transfer: the client sends a Range: bytes= header asking for only part of the representation. When that requested range cannot be satisfied, the server replies 416 instead of streaming data.

A correct 416 response should include a Content-Range: bytes */<total-size> header telling the client the total size of the resource without the asterisk range. That lets the client retry with a valid range or fetch the whole resource.

Common causes

• A stale or incorrect media offset. A video or audio player asks to resume at an offset beyond the end of the file after the file was replaced or truncated.
• A download manager has a saved range from a previous download that no longer matches the current file size.
• A zero-byte range such as bytes=0-0 sent against an empty resource, which has no valid range to serve.
• Reproducible resuming against a resource whose size differs between requests, for example a dynamically generated payload that changes length each read.
• A range that is entirely above the file size, for example Range: bytes=5000- on a file only 1,000 bytes long.

Responding correctly

When you operate the server, make sure resumable downloads are served as static files that stay the same size between requests. CDNs and caching layers handle range requests for buffered content; the standing rule is to keep the origin consistent:

• Serve downloads from stable file paths rather than regenerating the body on every request.
• Check that the storage backend supports range reads; otherwise resuming always fails.
• Return the correct Accept-Ranges header so clients know ranges are supported.
• When a range cannot be satisfied, respond 416 with the Content-Range: bytes */<size> size so the client can recover.

For clients, the fix is retrying without the range header so the full file is fetched, then resuming from a fresh valid offset.

Range requests are the transport that underlies cache revalidation, so HTTP 304 Not Modified is the related success path for conditional fetches. Also worth knowing are HTTP 400 for malformed requests and the HTTP status list that places 416 among the client error family.