Cloud Upload Interrupted Halfway? Do Not Assume the Progress Bar Can Resume From the Same Byte

Short answer: sometimes a large cloud upload resumes from the last confirmed byte range. Sometimes the application simply retries the file. Sometimes the browser must start again. And sometimes the service keeps temporary or partial upload state that is not yet a valid final file.

The mistake is treating “upload progress reached 63%” as if it proves the cloud has a durable 63% of the final file that every client can resume later.

That percentage can describe very different states:

• bytes sent by your computer;
• bytes acknowledged by the server;
• chunks committed to a resumable upload session;
• temporary local cache;
• a partial server object;
• or merely the current desktop sync queue.

If the file matters, the useful question is not:

Did the progress bar resume?

It is:

Which bytes did the remote service confirm, is the upload session still valid, and how will I prove the final remote file is complete?

“Resume” can mean three different things

Before comparing providers, separate three mechanisms that are often called the same thing.

A fourth case is particularly dangerous: partial-file persistence. A service or API may retain an incomplete object after the connection breaks. That can be useful for tooling, but it means “a file with the right name exists remotely” is not automatically proof that the upload completed.

This is why large-file transfer reliability should be tested separately from Cloud Backup vs Cloud Storage. A sync engine that retries well is still not an independent backup merely because it survived a Wi-Fi dropout.

Dropbox: the API has real upload sessions, while the desktop app is the better user path for very large files

Dropbox currently recommends its desktop app for files above the website's upload limit. Its current help documentation says uploads through dropbox.com can be up to 350 GB per file/folder, while the desktop app supports files up to 2 TB.

For developers, Dropbox exposes something more precise than a generic progress bar: upload sessions.

The Dropbox API supports a sequence built around:

1. upload_session/start;
2. one or more upload_session/append_v2 calls;
3. upload_session/finish.

Dropbox documents that upload sessions can remain usable for up to seven days. The client tracks the session and the upload offset, so a large transfer does not have to be represented as one monolithic HTTP request.

That is a genuine resumable/chunked transfer primitive.

But do not convert that API fact into a promise that every Dropbox upload path behaves identically. The website, desktop app and API are different transfer paths. Dropbox's public consumer help does not give the same byte-range protocol explanation for every desktop interruption scenario.

What to do after Dropbox loses the connection

For a normal user:

• leave the source file in place;
• reconnect the network;
• let the desktop client settle;
• confirm Dropbox reports the item as fully synced;
• then verify the cloud copy from the web or another device;
• for critical archives, independently re-download and hash a sample before deleting the source.

Do not delete the local source merely because the desktop client stops showing an error.

Google Drive: resumable upload is explicit and queryable

Google's current Drive API documentation provides one of the clearest resumable-upload models.

A client can initiate an upload with uploadType=resumable. Google returns a resumable session URI. The file can then be sent in one request or in multiple chunks.

If the connection breaks, the client can query that same session URI to determine what the server actually received.

Google documents the recovery flow like this at the protocol level:

1. send an empty request to query the upload status;
2. inspect the response;
3. if the server returns 308 Resume Incomplete, read the acknowledged byte range;
4. continue from the next missing byte;
5. if the session has expired and returns 404, start the upload again.

Google currently says a Drive resumable-session URI expires after one week.

That distinction is important because it separates bytes the client attempted to send from bytes the server says it has.

Drive for desktop is not the same as writing your own resumable API client

Google Drive for desktop is still the safer consumer path for large background transfers than repeatedly dragging huge files into a browser window. But CloudScope will not claim the desktop client exposes the exact same resumable-session lifecycle to the user just because the Drive API supports it.

What you can verify as a user is simpler:

• the file leaves the local pending/uploading state;
• it appears remotely;
• its size is correct;
• it can be downloaded from a second path;
• and, when integrity matters, the downloaded bytes match the source.

The protocol matters to developers. The verification outcome matters to everyone.

OneDrive: Microsoft Graph has resumable upload sessions with explicit missing ranges

Microsoft Graph also exposes a true resumable large-file upload mechanism.

The createUploadSession API creates a temporary upload session and lets the client upload file ranges sequentially. Microsoft documents nextExpectedRanges, which tells the client which byte ranges the server is still missing.

If a request fails because the connection drops, the bytes from the failed request are ignored, but previously completed fragments remain usable within the session. The client can query the session URL, retrieve the missing range, and resume from the last server-confirmed fragment.

Microsoft also documents an expiration time for the upload session. Each successful fragment can extend that expiration window. If the session disappears and the API returns 404, the correct recovery is to start the upload again.

That is a much stronger statement than “OneDrive usually resumes.” It defines the boundary of the resumable state.

OneDrive's consumer guidance still prefers the desktop app for large transfers

Microsoft currently recommends the OneDrive desktop app rather than the website Upload button for very large files or large batches. The website can accept very large files in modern browsers, but a browser upload and a Graph upload session are not the same operational workflow.

So if you are moving a 100–200 GB archive over an unstable connection, the safe decision is not to assume the web page will preserve your exact byte position indefinitely. Use the desktop app or a tool that explicitly uses resumable upload sessions, then verify the result.

iCloud Drive: Apple shows transfer state, but consumer documentation does not promise an iCloud-specific resumable byte-range contract

On macOS, Apple exposes useful iCloud Drive status information in Finder. A file can show states such as:

• Waiting to Upload;
• a transfer-progress pie chart;
• In iCloud;
• Downloaded;
• or an error such as Out of Space / Ineligible.

That helps you distinguish a file that has not yet reached iCloud from one that is current between the Mac and iCloud.

What Apple does not document in its normal iCloud Drive consumer help is an iCloud-specific byte-range session API equivalent to Google Drive's resumable URI or Microsoft Graph's nextExpectedRanges.

Apple's broader Foundation networking stack does support resumable HTTP uploads in modern OS versions when the remote server also supports the relevant resumable-upload protocol. That is an application-development capability, not proof that every ordinary iCloud Drive upload exposes that exact mechanism to the user.

So the correct consumer conclusion is narrower:

Use Finder's iCloud status to determine whether the item is still waiting or has completed, but do not infer a documented byte-level resume guarantee that Apple has not published for the iCloud Drive workflow.

If the Mac loses connectivity during a huge iCloud Drive transfer, preserve the source, reconnect, let Finder settle, and verify the final remote copy before removing anything local.

pCloud: the desktop app is designed to tolerate interruptions, but the low-level API exposes a different partial-upload model

pCloud's current help documentation says pCloud Drive uses local cache during file transfers to make uploads more efficient and to reduce disruption when the internet connection is interrupted. Its Sync workflow also says changes synchronize after connectivity returns.

That is useful consumer behavior.

The pCloud HTTP API, however, exposes an important low-level detail: its normal uploadfile method can keep a partially uploaded file if the connection breaks before the full file is read. The optional nopartial flag tells the API not to save such a partial upload.

The API also supports progresshash together with the uploadprogress method so a client can inspect the progress of a currently running upload.

This is not the same design as Google Drive or OneDrive's documented resumable byte-range upload sessions.

CloudScope therefore will not describe pCloud's basic uploadfile endpoint as if it were a Google-style resumable session that can always reconnect later and ask for the next missing range. The official API documentation supports progress monitoring and partial-file behavior; it does not document the same resumable-session contract.

The practical pCloud path is the native desktop workflow, not a DIY assumption about partial files

For normal users, pCloud's desktop app is the relevant path. pCloud explicitly says its local cache helps prevent interruptions from unstable internet, and its Sync feature catches up after reconnection.

For developers using uploadfile, decide deliberately whether partial remote files are acceptable:

• use nopartial if an incomplete remote object is worse than restarting;
• monitor upload progress if needed;
• treat the upload as incomplete until the final API response confirms success;
• then verify the resulting object.

This is a good example of why “the service supports interrupted uploads” is too vague to be technically useful.

The Big 5 comparison: what is actually documented

This table is deliberately conservative. It compares what the vendors document, not what we assume their private desktop protocols must be doing internally.

Why a progress bar can lie without actually being wrong

Suppose a 100 GB upload reaches 80% and the Wi-Fi fails.

Several entirely valid implementations could exist:

Model A: 80 GB is committed server-side

The client reconnects, queries the session, sees that bytes 0–79 GB are acknowledged, and continues from byte 80 GB.

Model B: the last 10 GB request failed atomically

The UI showed 80 GB sent, but the server only committed 70 GB. A correct resumable client queries the server and retransmits from 70 GB.

Model C: the desktop client cached a transfer job locally

The progress bar represents application state. After restart, the application rescans the source and decides what to retransmit.

Model D: the browser request died

The visible 80% has no reusable server session exposed to you. You start the file again.

Model E: the server retained an incomplete object

A partial file or temporary object exists remotely but is not a valid final upload.

All five can produce a UI that looked like “80% uploaded.”

That is why the correct verification boundary is the final remote object, not the progress indicator.

Do not modify the source file while a resumable upload is paused

A resumable transfer depends on the source still representing the same file.

If you start uploading a 200 GB disk image, interrupt at 120 GB, then an application modifies the first 50 GB before the upload resumes, the meaning of “continue from byte 120 GB” becomes dangerous unless the client detects the change and restarts safely.

This is especially relevant for:

• virtual-machine disk images;
• databases;
• Lightroom or media catalogs;
• PST/OST mail stores;
• large archives that are still being written;
• exports that another process is replacing in place.

For changing application data, first create a stable snapshot/export. A generic file sync engine is not a transaction-aware database replication system.

Interrupted upload does not mean you should delete the remote partial object immediately

If you find a partial-looking file remotely, stop and identify the transfer path before deleting anything.

With one system, it may be an abandoned incomplete object. With another, it could be part of a still-recoverable upload workflow. With a desktop sync client, deleting it remotely can itself propagate a deletion or create a second conflict when the local client reconnects.

Use this order instead:

1. Pause active changes to the source.
2. Identify the upload path — browser, desktop sync, API, migration tool, NAS connector.
3. Check whether the application still owns an active transfer/session.
4. Check remote size and status.
5. Resume/retry through the same supported path.
6. Only clean up abandoned partial objects after the final object is verified.

The instinct to “delete the broken cloud copy and start clean” can turn a recoverable transfer into duplicate work or a sync deletion event.

A safer large-file transfer test before moving terabytes

Do not learn your provider's interruption behavior during a 4 TB migration.

Use a representative file first — large enough that the transfer runs for several minutes on your connection.

Test 1: normal completion

Upload the file and verify:

• remote size;
• remote visibility from a second device or web UI;
• clean download;
• checksum match if integrity matters.

Test 2: short network interruption

Disconnect the network briefly, then reconnect.

Observe:

• does the client resume automatically?
• does the UI restart from zero?
• does the server object appear before completion?
• does final transfer time suggest the client resent a large portion?

Do not infer exact protocol internals from transfer time alone; use it only as an operational observation.

Test 3: application restart

Interrupt the upload, close the application cleanly, reopen it, and observe whether the transfer continues or restarts.

Test 4: machine reboot

Only after preserving the source, test a full restart if that scenario matters for your workflow.

Test 5: destination conflict

For an API/migration pipeline, test what happens if a same-name destination object appears while the upload is still in progress.

Then document the behavior. A transfer workflow you have actually verified is more valuable than a marketing sentence that says “automatic sync.”

Verification after the upload resumes is mandatory

A resumed transfer that reaches 100% still needs an end condition.

For ordinary files, check:

• exact filename;
• expected path;
• exact byte size;
• remote modified/created metadata if that matters;
• ability to download/open from another path.

For critical archives, add an integrity test.

A robust sequence is:

1. hash the stable source before upload;
2. upload / resume until the cloud reports completion;
3. obtain a provider-side checksum where the service exposes one or re-download the object independently;
4. hash the downloaded copy;
5. compare the fingerprints exactly;
6. retain the source until the comparison passes.

If you are building an archive migration rather than solving one broken upload, keep a manifest of path + size + checksum. That lets you prove the destination instead of trusting thousands of individual green icons.

When retrying from zero is actually the correct behavior

Resumability is useful, but continuing an old session is not always safer.

Start over when:

• the upload session has expired;
• the server says the session no longer exists;
• the source file changed;
• the destination path changed in a way the session cannot safely commit;
• the client cannot determine which bytes the server received;
• the temporary state is inconsistent;
• or the vendor explicitly instructs the client to create a new session.

A clean restart wastes bandwidth. A guessed resume point can produce something worse: uncertainty over what object the destination actually contains.

Which provider is best on unreliable internet?

There is no honest universal winner from the public documentation alone.

Choose Dropbox if…

You already use its desktop workflow and need mature large-file sync, while developers can use documented upload sessions. Do not confuse the API's session guarantees with every browser workflow.

Choose Google Drive if…

Your custom tooling benefits from a clearly documented resumable session URI and server-acknowledged byte ranges, and Google's broader Workspace integration still matters.

Choose OneDrive if…

You are in the Microsoft ecosystem and want a documented Graph upload-session model with explicit missing byte ranges. For consumers moving huge files, use the desktop app rather than depending on a browser upload.

Choose iCloud Drive if…

Your priority is Apple-native integration and Finder-based file state rather than a documented public resumable-upload API for arbitrary cloud migration tooling.

Consider pCloud if…

You want a storage-first desktop workflow where local cache helps tolerate unstable connectivity and Sync catches up after reconnection. But if you are writing custom upload code, respect the actual uploadfile semantics: progress monitoring and optional partial-file persistence are documented; a Google-style resumable-range session is not.

If your real problem is not connection reliability but the amount of local disk required by a cloud-first workflow, read How pCloud Drive Cache Actually Works. If you are still deciding whether the archive belongs in cloud storage or on local hardware at all, use Cloud Storage vs External Hard Drive.

The rule that prevents the expensive mistake

The dangerous moment is not when the internet goes down.

It is when the connection comes back, the progress bar eventually reaches 100%, and you interpret that as permission to erase the source.

Do not make that jump.

For a valuable file, the process is:

stable source → supported upload path → resume/retry → remote completion → independent verification → only then source cleanup

The provider can manage retries. You still own the proof that the final object is the one you meant to store.

Sources and verification

Product behavior changes. CloudScope checked the following primary vendor documentation on 21 August 2026:

1. Dropbox Help — Uploading to Dropbox: https://help.dropbox.com/create-upload/add-files
2. Dropbox SDK — Upload sessions and session lifetime: https://dropbox.github.io/dropbox-sdk-js/Dropbox.html
3. Google Drive API — Upload file data / resumable uploads: https://developers.google.com/workspace/drive/api/guides/manage-uploads
4. Microsoft Graph — Create upload session: https://learn.microsoft.com/en-us/onedrive/developer/rest-api/api/driveitem_createuploadsession?view=odsp-graph-online
5. Microsoft Support — Upload files to OneDrive: https://support.microsoft.com/en-US/onedrive/upload-photos-and-files-to-onedrive
6. Apple Support — Check iCloud Drive file and folder status on Mac: https://support.apple.com/en-ca/guide/mac-help/mchlc994344b/mac
7. Apple Support — Upload and download files from iCloud Drive on iCloud.com: https://support.apple.com/en-gb/guide/icloud/mmad632d1df2/icloud
8. Apple Developer — Pausing and resuming uploads: https://developer.apple.com/documentation/foundation/pausing-and-resuming-uploads
9. pCloud Help — Uploading, Downloading, and Organizing Files: https://help.pcloud.com/article/uploading-downloading-organizing
10. pCloud API — uploadfile: https://docs.pcloud.com/methods/file/uploadfile.html
11. pCloud API — uploadprogress: https://docs.pcloud.com/methods/file/uploadprogress.html