A large download reaches 80%, your connection drops, and then two very different things can happen. One download continues from roughly where it stopped. Another starts again from zero.
The difference is not simply whether your internet connection is fast or stable. Resuming works only when the downloading app can keep the data it already received and the server can provide the missing part in a way that still belongs to the same file.
A useful mental model is to think of a download as filling a numbered sequence of bytes. If the first part is already safely stored, the downloader may be able to ask for the sequence starting at the first missing byte instead of requesting the whole file again.
A download does not have to arrive in one uninterrupted stream
When you download a file from the web, your browser or another app requests data from a server and writes the received bytes to local storage. If the connection ends early, the partial data does not automatically become useless.
Suppose a file contains 1,000 MB of data and your device has already received the first 700 MB. If both sides support the necessary behavior, the downloader can make another request for the remaining portion rather than downloading the first 700 MB again.
HTTP, the protocol commonly used to transfer web content, supports range requests. A range request asks a server for only a specified part of a resource. The standard byte range is based on positions in the resource, so a client can effectively ask for data from a particular byte onward.
If the request is valid and the server handles it as a range request, the server can respond with HTTP status 206 Partial Content and return only the requested portion. The downloader then combines that new data with the part it already has.
This is the basic mechanism behind many resumable web downloads.
The downloader must remember what it already has
Server support is only half of the process. The browser, download manager, or other client also needs to preserve the partial file and enough information to continue correctly.
An interrupted download may therefore leave a temporary or partially completed file on the device. The exact filename and storage method depend on the application. Some apps keep partial data automatically, while others may remove it after a failed or cancelled transfer.
This distinction matters because pause, connection failure, and cancel do not necessarily mean the same thing. An application may treat pausing as an instruction to retain the partial download for later, while cancelling may mean that the user no longer wants the transfer and its temporary data can be discarded.
There is no universal rule for how every browser or app presents these actions. What matters technically is whether the already received bytes remain available and whether the client retains the information needed to request the rest.
The server must be able to provide the missing part
HTTP servers can indicate support for range requests with the Accept-Ranges response field. For byte ranges, a server can advertise Accept-Ranges: bytes.
That field is useful guidance, but it is not an absolute guarantee about a later request. The HTTP specification allows clients to attempt range requests even without seeing Accept-Ranges, and conditions can change between requests. A server can also ignore a range request in circumstances where it cannot or does not want to serve the resource that way.
This explains why a download being delivered over HTTP does not automatically make it resumable. The server, any relevant intermediary, and the application still have to handle partial retrieval in a compatible way.
Some downloads also come from systems whose generated links or authorization state expire. Even if the underlying transfer technology supports ranges, the application may be unable to resume later if it can no longer access the same resource.
Resuming only makes sense if the file is still the same
There is a more subtle problem than finding the correct byte position: the resource might have changed.
Imagine that you downloaded the first half of a software package yesterday. Today the server replaces the file with a newer version at the same address. Simply attaching the second half of the new file to the first half of the old one could produce a corrupt result.
HTTP provides validators to help clients determine whether a representation is still the same. One common validator is an entity tag, or ETag, which is a server-provided identifier associated with a particular representation. A server can also provide modification information, although the strength and suitability of validators vary.
For resuming, HTTP defines the If-Range request field. In simplified terms, it lets a client say: send the requested range if the representation is still the one I have; otherwise, send the complete current representation.
That is an important safety property. A reliable resume process is not merely “continue at byte 700 MB.” It is closer to “continue at this position only if those bytes still belong to the same version of the resource.”
Why a download may restart from zero
When an interrupted transfer cannot resume, several different causes can lead to the same visible result.
The partial data may have been deleted. The application may not implement resuming for that type of transfer. The server may not honor range requests. The download address or authorization may no longer be valid. The resource may have changed, making the old partial copy unsuitable for continuation. An application may also choose to restart because it cannot verify that combining old and new data would produce the intended file.
For the user, these cases can all look like a progress bar returning to zero, but the underlying reasons are different.
This is also why installing a different download manager cannot guarantee that every download will become resumable. A capable client can make better use of server features, but it cannot force a server to provide a valid missing range or restore access to an expired resource.
Resuming does not mean the transfer survived entirely in memory
A common misconception is that a paused download remains alive somewhere in RAM until you continue it. That would be impractical for large files and would not survive an application or device restart.
Resumable download systems generally rely on data already written to persistent storage, together with metadata that lets the application understand what has been received. The implementation details vary, but the important idea is that useful partial data can outlive the network connection that delivered it.
This also explains why deleting temporary download data, clearing an application’s stored data, or removing the partial file can eliminate the ability to resume. The server may still support ranges, but the client no longer has the earlier portion to build on.
What to do when a large download is interrupted
If an app offers Resume or Retry, using that control first is usually sensible. A retry does not necessarily mean starting over; the application may inspect its saved state and continue if the server allows it.
Avoid deleting the partial file or clearing the application’s download data while you still hope to resume. If the original download came from a temporary or signed link, returning to the source and obtaining a fresh link may be necessary, although whether existing partial data can be reused depends on the service and application.
For especially large downloads, a tool designed to preserve and resume partial transfers can be useful when the source supports that behavior. But the server remains part of the decision, so resumability should be treated as a capability of the whole transfer rather than a property of the client alone.
The practical takeaway
A resumable download works because the transfer can be divided into identifiable parts. The client saves the bytes it has already received, asks the server for the missing range, and makes sure that the new data still belongs to the same resource before combining the pieces.
When any part of that process is unavailable, restarting from zero may be the only reliable option.
The progress percentage therefore tells you how much data has arrived, not whether that progress is guaranteed to survive an interruption. Resuming depends on what the downloader saved, what the server can provide, and whether both sides can establish that they are still working with the same file.