416 Range Not Satisfiable

The server cannot supply the requested byte range because it falls outside the resource's current size.

Defined in RFC 9110 §15.5.17

What 416 means

RFC 9110 defines 416 for when a request carries a Range header that the server cannot honor because none of the specified byte ranges overlap the current length of the selected representation. Rather than silently returning the full resource or an error unrelated to ranges, the server signals precisely that the range itself is the problem, and should include a Content-Range header set to "bytes */actual-length" so the client learns the real size.

In practice this shows up constantly in resumable downloads and media streaming. A download manager that paused a transfer and later resumes it with Range: bytes=500000- will get a 416 if the remote file has since shrunk, been replaced, or was truncated. Video and audio players that seek by requesting a byte range past the end of a (possibly still-transcoding) file trigger the same response.

Browsers rarely surface 416 directly to end users; instead, download managers, media players, and HTTP client libraries catch it and fall back to a full GET or restart the transfer from zero. Every major web server and CDN (nginx, Apache, CloudFront, Cloudflare) implements 416 as part of standard Range/Accept-Ranges support, so it is a normal, expected part of partial-content workflows rather than an edge case.

Common causes

Client requests a byte range starting beyond the end of the resource, often while resuming a download after the file was truncated or replaced.
Client sends Range: bytes=1000-2000 for a resource that is now smaller than 1000 bytes.
A download manager resumes a partial transfer using a stale Content-Length recorded from a previous session.
The Range header contains overlapping, out-of-order, or malformed ranges the server refuses to satisfy.
A media player seeks past the actual duration of a truncated or still-processing video or audio file.
Server-side range validation is stricter than the client expects, such as rejecting open-ended suffix ranges.

How to fix a 416

If you are the client (browser user or API caller)

Re-request the resource without a Range header to fetch the full, current representation.
Read the Content-Range header in the 416 response to learn the actual resource length and issue a corrected range.
Clear any cached partial-download state before resuming, in case the remote file changed since the last attempt.
Fall back to a full GET automatically when a ranged request is rejected, rather than retrying the same range.

If you run the server

Always include a Content-Range header (bytes */actual-length) on the 416 response so clients can self-correct.
Validate incoming Range headers against the resource's current length before processing the request.
Keep Content-Length and ETag in sync whenever a file changes, so range resumption can detect staleness reliably.
Support the If-Range header so clients can safely combine conditional checks with range requests in one round trip.

Example

GET /videos/lecture.mp4 HTTP/1.1
Host: cdn.example.com
Range: bytes=9000000-9500000

HTTP/1.1 416 Range Not Satisfiable
Content-Range: bytes */8421376
Content-Type: application/json

{"error": "requested range starts beyond the end of the resource"}

The Content-Range header tells the client the resource is only 8,421,376 bytes long.

Try it live

Our free status responder returns a real HTTP 416 you can point tests, monitors or a browser at.

GET https://mcp.httpstatus.com/status/416