416 Range Not Satisfiable 4xx

What does 416 mean?

A 416 Range Not Satisfiable response means the client requested a specific byte range of a resource (via a Range header) that doesn't correspond to anything within the resource's actual size — for example, requesting bytes 1000-2000 of a file that's only 500 bytes long. This is part of HTTP's range request mechanism, most commonly associated with video streaming, resumable downloads, and partial file fetching.

416 is the error counterpart to 206 Partial Content (the success response when a range request can be satisfied) — together they form HTTP's built-in support for fetching just part of a resource rather than the whole thing.

How a 416 behaves

• It typically includes a Content-Range header indicating the actual size of the resource (e.g., Content-Range: bytes */500), helping the client understand what ranges would be valid
• It can carry a body, though often minimal
• It's the result of a Range header in the request — without one, range-related errors don't apply, and a normal 200 (or other appropriate code) would be returned instead
• Most range requests succeed (206) or are ignored (200, full resource returned) — 416 specifically represents a range request for something fundamentally outside the resource's bounds, not just "the server doesn't support ranges" (which would more typically result in returning the full resource with 200 instead)

Common causes

If you're building the API or website:

• A client requested a byte range beyond the actual file size — this can happen if the client has stale information about a file's size (e.g., the file was replaced with a smaller version, but the client's metadata is outdated)
• A bug in range-handling logic is generating invalid range headers for legitimate requests

If you're calling an API:

• You're implementing resumable downloads and have stale information about a file's total size — perhaps the file was updated/replaced server-side since you last checked its size
• A range calculation in your code has an off-by-one error or similar bug, requesting a range that doesn't correspond to valid byte positions

If you're a website visitor:

• Resuming a paused download or video stream where the underlying file has changed (been replaced with a different version) since the download started, so your "resume from byte X" request no longer makes sense for the new file
• Rare in normal browsing — range requests are typically handled transparently by browsers for media playback and downloads

How to fix it

As an API/website builder:

• Always include Content-Range: bytes */<actual-size> on 416 responses, giving the client the information it needs to retry with a valid range
• If files can be replaced/updated, consider how this affects clients with in-progress range-based downloads — using ETag or Last-Modified validation alongside range requests can help clients detect when a file has changed and they need to restart rather than resume

As an API consumer:

• If implementing resumable downloads, check the Content-Range header on a 416 response to learn the resource's actual current size, and adjust your range request accordingly (or restart the download if the resource has fundamentally changed)
• Validate that your range calculations are correct — off-by-one errors in byte-range math are a common source of unexpected 416s

As a website visitor:

• If a download or video won't resume properly, try restarting it from the beginning — the underlying file may have changed since your download started

206 vs 416

Real-world examples

Video streaming and resumable download implementations rely heavily on range requests (206 for valid ranges) — 416 specifically surfaces in edge cases like a download client requesting "the rest of the file starting from byte X" when the file has since been replaced with a smaller file, making byte X beyond the new file's end. Media players implementing seek functionality (jumping to a specific point in a video) use range requests to fetch just the relevant portion of a file, and 416 would indicate a seek position that's somehow beyond the actual file's bounds — usually indicating a bug in how the seek position was calculated relative to the file's real size.

SEO implications

416 is exclusively relevant to byte-range requests for media/file resources and has no bearing on page-level SEO or content indexing.

FAQ

What's the relationship between 416 and 206?

They're two outcomes of the same mechanism — range requests. 206 is the success case (the requested range is valid, here's that portion of the resource). 416 is the failure case (the requested range doesn't correspond to anything in the resource's actual size).

Why would I get 416 when resuming a download?

This usually means the file has changed since your download started — if the file is now smaller than it was, "resume from byte X" might now be requesting a position beyond the new file's end, which can't be satisfied.

What does the Content-Range: bytes */500 header mean on a 416 response?

The * indicates "no specific range," and /500 indicates the resource's actual total size is 500 bytes — telling the client what the valid range would need to be relative to (0-499 in this case), even though the requested range wasn't valid.

Is 416 common in normal web browsing?

Very rare — range requests are mostly relevant to media streaming and download managers, which handle this internally. Regular page browsing (HTML, CSS, JS, images loaded normally) typically doesn't involve range requests at all.

Can 416 indicate a bug in my application's range-handling code?

Yes — if you're implementing range request logic (for serving large files, video streaming, etc.) and seeing unexpected 416s, it's worth double-checking the byte-range math for off-by-one errors or incorrect assumptions about file sizes, especially if files can be updated/replaced after clients have already started range-based requests against them.

Fun fact

416 is part of a small cluster of status codes (alongside 206 and the Range/Content-Range/Accept-Ranges headers) that together implement what's essentially a "partial file transfer protocol" within HTTP itself — a feature that predates and, in some ways, anticipated patterns that later became central to how streaming media and large file distribution work across the modern web, all built on infrastructure defined decades ago.