HTTP 416 Range Not Satisfiable
HTTP 416 Range Not Satisfiable (RFC 9110) is returned when a request includes a Range header whose ranges all fall outside the resource's current size — for example asking for bytes starting past the end of the file. The server cannot return the requested range and responds 416, usually with a Content-Range header stating the resource's total length.
What this means
Range requests let a client ask for part of a resource using the Range header, which powers resumable downloads and media seeking. The server answers a valid partial request with 206 Partial Content. A 416 Range Not Satisfiable is returned when none of the requested ranges overlap the resource's current representation — typically when the start offset is at or beyond the resource length.
Per RFC 9110, a 416 response should include a Content-Range header of the form 'bytes */length' so the client learns the true size and can retry correctly.
Common causes and fixes
The usual cause is a stale notion of the file's size: a client resumes a download from an offset that was valid for an older, larger version of the file, or a CDN cache holds a different length than the origin. Crawlers that fetch ranges for large assets can hit this when content rotates.
To fix, ensure the resource size is consistent across origin and any cache layers, always emit a Content-Range total on 416 responses, and make sure ETag/Last-Modified change when the file changes so resumed requests are invalidated rather than producing out-of-range offsets.
- Range header offset is past the end of the resource
- Include 'Content-Range: bytes */length' on the 416 response
- Keep file length consistent across origin and CDN caches
How it appears in analytics and logs
A 416 means a client (or crawler resuming a fetch) asked for a byte range the resource cannot supply. Repeated 416s on a media or download URL often signal that a client believes the file is larger than it is, commonly after the file changed size.
Diagnostic use case
Diagnose why a partial-content request fails: a 416 means the requested byte range does not exist, often from a stale resumed download or a mismatched cached length.
What WebmasterID can help detect
WebmasterID records the status returned to crawler fetches, so recurring 416 responses on large files appear in bot-intelligence and point to range or caching mismatches rather than missing pages.
Common mistakes
- Omitting the Content-Range total on a 416 so clients cannot learn the real size.
- Letting a CDN cache a stale length that no longer matches origin.
- Not changing the ETag when a file's size changes, so resumed ranges go stale.
- Treating a 416 as a missing page (404) when it is a range problem on an existing resource.
Privacy and accuracy notes
A 416 is a protocol response about byte ranges, not visitors. WebmasterID records crawler fetch statuses without attaching them to a person.
Frequently asked questions
- Is a 416 the same as a 404?
- No. A 404 means the resource does not exist; a 416 means the resource exists but the requested byte range does not. The fix for a 416 is about ranges and sizes, not missing URLs.
Related pages
- HTTP 206 Partial Content and range requests
206 Partial Content is the response to a range request: the client asked for a byte range of a resource and the server returned just that portion. It underpins resumable downloads and media streaming, where players fetch a file in chunks. In crawler logs it usually reflects media or large-file fetching rather than page crawling.
- HTTP 417 Expectation Failed
HTTP 417 Expectation Failed (RFC 9110) is returned when the expectation in a request's Expect header cannot be met by the server or an intermediary. In practice the Expect header is almost always 'Expect: 100-continue', a handshake clients use before sending a large body. A 417 usually points to a proxy or server that does not support that handshake.
- How CDNs interact with crawlers
A CDN sits between crawlers and your origin, so it shapes what crawlers see: cached responses, edge-served status codes, bot-management challenges, and region-specific edges. Configured well, a CDN speeds crawling and absorbs load; configured poorly, it can block legitimate crawlers, serve stale or wrong content, or return CDN-specific errors that look like origin problems. Understanding the interaction prevents silent crawl failures.
- Website observability
See range and partial-content status codes returned to crawlers, server-side.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.