416 Range Not Satisfiable

What’s actually happening

A download manager or media player asks for a byte range the server can't fulfill, so the transfer stalls or errors instead of resuming. It typically happens when resuming an interrupted download whose file shrank or was replaced, or when seeking in a video that changed on the server since playback started. The response often carries a Content-Range: bytes */<size> header telling you the real current length. A fresh request for the whole file usually works; only the ranged resume fails.

Common causes

• Resuming a download from a saved offset, but the server-side file is now smaller than that offset (replaced or truncated).
• A video player seeking to a timestamp beyond the current file after the asset was re-encoded or swapped.
• A stale or corrupt cached partial file telling the client to request bytes that no longer exist.
• A CDN or origin serving a different version of the file than the one the client started, so the byte ranges don't line up.
• A buggy client sending a malformed Range header (start beyond end, or a negative/zero-length range).

How to fix it

1. Restart the download from scratchDelete the partial file and re-download without a resume offset. In curl, drop -C - (or run curl -C - again only after confirming the remote file is unchanged). A clean GET with no Range header sidesteps the mismatch.
2. Clear the cached partial/range dataRemove the browser cache entry or the download manager's stored chunk for that URL. Stale offsets are a frequent cause — once cleared, the client requests the file fresh and re-reads its real size.
3. Confirm the file's current sizecurl -sI https://example.com/file.zip and read Content-Length, or look at the Content-Range: bytes */N in the 416 response. If N is smaller than where your client is resuming from, the file changed — start over.
4. Version asset URLs so clients don't mix versionsIf you control the server, add a hash or version to media URLs (file.v2.mp4 or ?v=hash) when content changes, so a re-encoded file gets a new URL and in-flight range requests never target the wrong bytes.