Transfer Stuck at 99%? What Is Actually Happening
The bar reached 99% ten seconds ago and has not moved. Whether that is normal depends on what the tool is doing in the last percent, and most tools do a lot there. This article walks through the end of a transfer step by step, explains why some tools pause for a long time at the finish line, and gives you a way to tell a slow finish from a failed one.
What happens after the last byte arrives
- Verification. A careful tool checks that what arrived is what was sent, usually by hashing the file (SHA-256 or similar) and comparing with the sender's hash. If the tool hashes after the transfer, this step reads the entire file again from disk: for a 4 GB file on a laptop hard drive, that is 30–60 seconds with the bar sitting at 99%.
- Finalisation. Data was written to a temporary file or held in memory; now it must become the real file. On a desktop browser without streamed writes (Safari, Firefox) this means assembling a Blob from chunks and handing it to the download manager: a large memory operation that can take seconds and, on a low-memory device, fail (why).
- Saving into a library. On phones, a received photo or video is not done when it is on disk; it is imported into the Photos library, which generates thumbnails and metadata. A 2 GB video can take a phone 10–20 seconds to import.
- Acknowledgement. The receiver tells the sender “verified,” and both sides mark the transfer complete. If the connection dropped just before this, the receiver may be done while the sender still shows 99%.
Why ShareDrop.org rarely pauses there
The expensive step is verification, and it is expensive only if it is done at the end. The ShareDrop.org engine hashes each 64 KiB chunk as it arrives, on both sides, so by the time the last chunk lands the hash of the whole file is already known — the final comparison is instant (how incremental hashing works). What remains is finalisation, which on Chrome and Edge is nothing (the file was written to its destination as it arrived) and on Safari, Firefox and mobile browsers is the in-memory assembly described above. If you see a pause at the end in those browsers, that is what it is.
Slow finish or real failure? Three checks
| Sign | Slow finish | Failure |
|---|---|---|
| Disk or CPU activity on the receiver | High — it is hashing, assembling or importing | Idle |
| Connection status | Still connected | Disconnected, reconnecting, or the other side shows an error |
| Time | Proportional to file size: seconds for hundreds of MB, up to a minute for many GB | Open-ended, with no activity |
Give a large file at least a minute at 99% before concluding anything. If the receiving device is visibly busy, wait. If it is idle and the connection indicator has changed, something interrupted the last exchange.
The usual causes of a genuine stall
- The sender's screen locked. A locked phone may suspend the browser or app; the receiver waits for the final acknowledgement that never comes. Unlock the sender and the transfer completes: good tools resume from the last confirmed chunk rather than starting over.
- Out of storage on the receiver. The last chunk cannot be written. Most tools check free space at the start; a device that filled up during the transfer (another app downloading) can still hit this.
- Hash mismatch. The file arrived but does not match. An honest tool reports this as a failure, not a completion: a “done” with a corrupt file would be worse. Retry; a persistent mismatch on the same file points at a faulty storage device on one side.
- Network change mid-transfer. A phone switching from Wi-Fi to cellular changes its address; the connection must be re-established. ShareDrop.org reconnects and resumes; tools without resume restart from zero.
Where each kind of tool spends its last percent
| Tool | What happens after the last byte | How long |
|---|---|---|
| Browser P2P with incremental hashing | Compare a digest already computed; finalise the file | Instant on Chrome/Edge; seconds on Safari/Firefox for large files |
| Browser P2P that hashes at the end | Read the whole file back and hash it | Proportional to size and disk speed |
| Upload-and-link service | Server-side virus scan and processing before the link works | Seconds to a minute; the bar may show 100% first |
| Cloud sync | Index, thumbnail, and propagate to other devices | Seconds; longer for many files |
| AirDrop / Quick Share | Write the file and import into the photo library | Seconds for large videos |
| Chat app | Server transcodes a video before delivery | Up to a minute for long videos |
What end-of-transfer hashing costs
For tools that verify only after the file has landed, the pause is a full read of the file from disk. At typical rates (around 500 MB/s on an SSD, around 100 MB/s on a laptop hard drive), that is:
| File | SSD | Hard drive |
|---|---|---|
| 500 MB | ~1 s | ~5 s |
| 2 GB | ~4 s | ~20 s |
| 10 GB | ~20 s | ~100 s |
Hashing as the chunks arrive costs the same total work but spreads it over the transfer, where the network is the bottleneck anyway, which is why it is effectively free (the mechanics).
Cancel or wait: a rule
Wait at least a minute, or the file size divided by 100 MB/s, whichever is longer. During that time, watch the receiver: disk or CPU activity means work is happening and cancelling will throw it away. If the time passes with the receiver idle and the connection indicator changed, the transfer is not going to finish on its own; let it reconnect if it can, and cancel only as the last resort — a tool with resume keeps the verified chunks, and one without has nothing to keep anyway.
The 100% that is not
Some tools show 100% when the sender has finished sending, not when the receiver has finished writing and verifying. The sender's bar reaching the end means the last chunk left; the receiver may still be assembling, importing or checking. If two screens disagree (sender at 100%, receiver at 99%), the receiver is telling the truth. ShareDrop.org marks a file done only when the receiver's hash has been acknowledged, so both screens agree by construction.
Preventing it next time
- Receive large files on a desktop in Chrome or Edge, where nothing is assembled in memory and the finish is instant.
- Check free space on the receiver before a large transfer, with a margin: phones need room for the temporary copy and the library import.
- Keep both screens awake for the last minute as well as the first; the acknowledgement at the end is a two-way exchange.
- Send one archive rather than thousands of small files when the structure does not matter; the per-file finish cost disappears.
And if you report a stuck transfer to whoever made the tool, four facts make it diagnosable: which browser or app on each side, the file size, what the badge said, and whether the receiving device was busy or idle during the pause.
A special case: folders and many files
With a folder transfer, the overall bar reflects bytes, and bytes are dominated by the big files. Ninety-nine percent of the bytes can arrive while hundreds of small files are still queued behind them (each needing its own open, write, hash and confirm), so the last percent genuinely contains most of the remaining work. A per-file counter, which ShareDrop.org shows alongside the bar, tells the real story: “412 of 1,300 files” at 99% of bytes means a few more minutes, not a stall.
What to do
- Wait a full minute if the file is large; watch the receiver for activity.
- Make sure the sending device is unlocked and the app or tab is in the foreground.
- Check free space on the receiver.
- If the tool offers resume, let it reconnect rather than cancelling — cancelling discards verified chunks.
- If it reports a checksum failure, retry once; if it recurs, suspect the disk, not the network.
And when you evaluate a transfer tool, ask when it verifies. “At the end” is the honest answer for many, and it is why their last percent takes so long.
