Cloud Storage File Size Limits: Which Service Actually Accepts Your Largest File?

Short answer: if your problem is a genuinely huge single file rather than a large folder, the five services do not behave the same. As of 21 August 2026, Dropbox documents a 2 TB maximum file size, Google Drive documents up to 5 TB for ordinary non-Google files, and OneDrive documents 250 GB per file. pCloud explicitly says Premium plans can upload files of any size, with the practical ceiling being the storage space available in the account. Apple's current iCloud Drive upload documentation, however, no longer publishes a numeric per-file maximum, so we do not treat the old 50 GB figure that still circulates online as a verified 2026 limit.

That first paragraph is the part most comparison pages get wrong. A cloud storage limit can mean at least four different things:

1. a hard per-file ceiling;
2. a browser upload ceiling or reliability threshold;
3. an account storage quota;
4. a daily transfer limit that can stop the next upload even when the file itself is allowed.

If you are moving video masters, virtual-machine images, database dumps, disk images or multi-hundred-gigabyte archives, those four limits matter more than the headline number on the pricing page.

The current file-size limits at a glance

The table does not mean pCloud is automatically the best cloud for everyone. Google Drive's 5 TB ceiling is already enormous, Dropbox's 2 TB limit covers most media workflows, and OneDrive's 250 GB ceiling is irrelevant if your biggest object is a 20 GB project file. The decision changes when the individual file itself is part of the storage design.

First diagnose which limit you actually hit

A failed 400 GB upload does not prove your cloud provider has a 400 GB file-size cap. Before changing services, identify the layer that rejected the upload.

1. Hard per-file limit

This is the simplest case. The service refuses an object because the object itself exceeds its supported maximum.

Examples from current official documentation:

• OneDrive: 250 GB per file.
• Dropbox: 2 TB per file.
• Google Drive: up to 5 TB for ordinary files.
• pCloud: no file-size restriction stated for Premium-plan uploads; the file must still fit your available storage.

If a 300 GB archive fails on OneDrive, compressing it from 300 GB to 280 GB does nothing useful. You either split the archive below 250 GB or use a service with a higher ceiling.

2. Browser upload limit or browser reliability threshold

This is where Dropbox becomes more interesting than a one-number comparison suggests.

Dropbox's newest file-size-limit page, updated in June 2026, says the maximum file size is 2 TB but warns that browser uploads larger than 375 GB may time out or be interrupted. A separate Dropbox upload article updated in April 2026 says files or folders uploaded through dropbox.com can be up to 350 GB, while the desktop app supports up to 2 TB.

Those two current Dropbox pages are not perfectly aligned. The safest operational rule is therefore conservative:

If a Dropbox upload is larger than roughly 350 GB, stop treating the browser as the correct transport and use the desktop app.

That is not the same as saying Dropbox cannot store the file.

3. Account quota

A service can technically support a 2 TB or 5 TB file and still reject it because your account has less free capacity than the object requires.

A 2 TB maximum does not help a Dropbox account with 600 GB free. Google's 5 TB file ceiling does not create 5 TB of quota. pCloud's no-per-file-limit rule similarly does not let a 3 TB file fit inside an account with 2 TB remaining.

For giant-file users, the useful capacity calculation is not:

largest file < provider maximum

It is:

largest file + growth + recovery headroom < usable account capacity

If you are storing one 1.7 TB disk image inside a 2 TB account, technically fitting the object is not the same thing as having a sensible storage plan.

4. Daily upload or copy ceiling

Google Workspace adds another layer. Google documents a 750 GB per-user upload-and-copy limit within 24 hours. A user who reaches the limit cannot upload or copy additional files until it refreshes.

There is a useful edge case: Google says files up to 5 TB can be uploaded or synchronized, and only the first file that breaks the 750 GB daily limit completes. So a 1.2 TB upload can complete, but the next upload can be blocked until the daily limit refreshes.

This is why "Google Drive max file size = 5 TB" is technically true but incomplete for migration planning.

Dropbox: 2 TB is the real file ceiling, but the browser is not the transport for giant files

Dropbox is stronger with large files than a lot of older comparison pages suggest. Its current file-size-limit documentation sets the hard maximum at 2 TB.

That makes Dropbox viable for:

• ProRes and other large video masters;
• VM disk images;
• large compressed project archives;
• workstation backups packaged as large objects;
• raw scientific or imaging datasets that stay below 2 TB per file.

But once files move into the hundreds of gigabytes, the upload method becomes part of the design. Dropbox explicitly recommends the desktop app or API for very large uploads rather than relying on a browser session.

When Dropbox is still the better choice

Choose Dropbox over pCloud if your files fit comfortably under 2 TB and your real priority is mature team sync, collaboration workflows, file requests and an existing Dropbox-centric operation. A theoretical no-limit advantage is worthless if every real object you store is 30 GB.

When the 2 TB boundary starts to matter

The pain appears when a workflow naturally creates single files over 2 TB: consolidated media masters, monolithic disk images, very large VM images, forensic images, or long-retention archives that cannot easily be split without changing the recovery process.

At that point, "just split the file" may be operationally acceptable—or it may be exactly the extra process you are trying to eliminate.

Google Drive: the highest verified numeric ceiling here, but do not ignore the 750 GB daily rule

Google Drive is the strongest conventional rival to pCloud for giant single files. Google's current Drive documentation says ordinary files can be as large as 5 TB.

That means a buyer with 1 TB, 2 TB or 4 TB individual objects does not need pCloud simply because the files are huge. If Google Workspace is already the centre of the team's document, identity and collaboration workflow, staying inside Google can be the cleaner architecture.

However, migration speed and per-file eligibility are different questions.

For Google Workspace, the 750 GB-per-user 24-hour upload/copy limit means a 5 TB-capable storage model can still throttle a large migration. Google explicitly allows the first file that crosses the limit to complete, which is why a multi-terabyte upload can behave differently from a folder containing hundreds of separate objects.

A concrete example

Suppose you need to move:

• one 1.4 TB VM image;
• one 700 GB project archive;
• another 600 GB archive.

Google's published rules can allow the first 1.4 TB file to complete even though it crosses the daily transfer limit. But additional upload/copy activity can then be blocked until the limit refreshes.

That is a throughput policy, not a 1.4 TB file-size rejection.

iCloud Drive: the uncomfortable answer is that Apple's current public guide does not state the number

This is where CloudScope deliberately refuses to repeat a stale number as if it were current.

Older Apple support material historically stated that iCloud Drive files had to be 50 GB or less, and that number is still repeated across forums and comparison sites. But the old Apple support URL now redirects to the current iCloud User Guide, and Apple's current "Upload and download files from iCloud Drive on iCloud.com" page explains the upload workflow without publishing a numeric maximum file size.

As checked on 21 August 2026, we therefore classify iCloud Drive this way:

Current public numeric per-file limit: not stated in the Apple documentation we could verify.

That is not the same as claiming iCloud has no file-size limit. It means the current source does not support a number strongly enough for us to print one as fact.

What should an iCloud user do with a 100 GB or 500 GB file?

If your workflow depends on reliably storing giant individual objects, test with a non-critical copy before designing the archive around iCloud Drive. If the Apple ecosystem is the main reason you use iCloud—Photos, device backup, Files integration and seamless Apple-device access—that ecosystem benefit may still outweigh the lack of a clearly published giant-file specification.

If the single-file size itself is a core requirement, a provider that publishes the rule explicitly is easier to engineer around.

OneDrive: 250 GB is clear, documented and often enough—until it suddenly isn't

Microsoft documents a 250 GB maximum for upload, download and sync of individual OneDrive/SharePoint files.

For ordinary office documents, photography and most project files, 250 GB is enormous. It becomes restrictive in a narrower but commercially important set of workloads:

• high-end video masters;
• disk images;
• workstation or server images stored as one object;
• VM disks;
• large CAD/BIM bundles that are packaged rather than decomposed;
• scientific datasets stored in monolithic containers.

Microsoft recommends the OneDrive sync app rather than web upload for files larger than a few gigabytes, but that does not change the 250 GB hard ceiling.

When OneDrive is still the rational choice

If Microsoft 365, SharePoint permissions, Office collaboration and Windows integration are central to the workflow, splitting a rare 300 GB archive can be cheaper than moving the whole storage architecture to solve one edge case.

If giant single files are routine rather than exceptional, the 250 GB boundary stops being an edge case and becomes a platform constraint.

pCloud: the advantage is not "bigger than Google"—it is the absence of a per-file ceiling

This is the distinction worth paying attention to.

pCloud's current pricing and product material states that Premium users can upload files of any size. A recent pCloud large-file guide makes the rule explicit: there are no file-size restrictions for uploads, regardless of account type, as long as the file fits the available storage quota.

That creates a different mental model:

• Dropbox asks whether the object is under 2 TB.
• OneDrive asks whether it is under 250 GB.
• Google Drive asks whether it is under 5 TB, then adds Workspace transfer policy on top.
• pCloud primarily asks whether the object fits inside your available storage.

For a user whose archive consists of giant immutable objects, that simplicity has real value.

But pCloud still has practical limits

"No file-size limit" must not be translated into "infinite upload."

The practical constraints still include:

• the storage capacity you bought;
• your remaining free quota;
• upload bandwidth and connection stability;
• local disk/cache requirements for some workflows;
• the time needed to upload and later restore a multi-terabyte object.

If you open huge remote files through pCloud Drive, local cache can still matter. Our separate explainer on how pCloud Drive cache actually works covers that distinction. pCloud Drive is a virtual-drive model, not magic zero-local-I/O storage.

Why this is more useful for archive buyers than collaboration-first buyers

A 3 TB video master is usually not being collaboratively edited by six people inside a browser. It is more often being archived, transferred, retrieved, versioned or kept as a source master.

That is exactly where pCloud's storage-first design becomes more persuasive:

• no published per-file size restriction;
• virtual-drive access instead of forcing the whole archive onto the laptop;
• optional Sync for folders that genuinely need local mirrors;
• long-term storage plans including current Lifetime options;
• separate client-side encrypted Crypto storage for selected sensitive files, if needed.

If your cloud decision is really about Docs/Sheets/Office collaboration, the giant-file advantage may be secondary. If your decision is about where multi-hundred-gigabyte or multi-terabyte objects live for years, it becomes central.

Big-file decision table: which service fits which object size?

The part most buyers miss: splitting a file is not always free

Technically, many hard limits can be bypassed by splitting an archive into chunks. That does not mean the workaround has zero cost.

A split archive changes the recovery procedure. Instead of one object, you now have a set that must remain complete. Naming, verification, checksum handling and restore instructions become more important. A missing segment can make the entire archive unusable depending on the format.

For an occasional 280 GB object on OneDrive, splitting it may be completely reasonable.

For a workflow that produces a new 600 GB or 3 TB object every week, repeatedly engineering around the provider's limit is a signal that the storage model may be wrong for the workload.

Many people discover this only after the first failed overnight upload. The more useful question is whether your next two years of files are likely to keep crossing the same boundary.

Large files also expose the difference between cloud storage and backup

Do not confuse "the service accepts my 4 TB disk image" with "I now have a complete backup strategy."

A single cloud copy is still one administrative domain. Account compromise, accidental deletion, sync propagation, billing failure or a corrupted source can still affect recoverability. If the file matters enough to justify a multi-terabyte cloud upload, it may also justify an independent second copy.

Read Cloud Backup vs Cloud Storage before treating any provider as the only recovery layer. For local-versus-cloud trade-offs, Cloud Storage vs External Hard Drive is the more relevant next step.

Which service should you choose for huge files?

Choose Dropbox if...

Your objects stay below 2 TB, Dropbox sync/sharing is already part of the workflow, and you are willing to use the desktop app for very large uploads rather than expecting the browser to carry hundreds of gigabytes reliably.

Dropbox is not disqualified by large files. It is disqualified only when the 2 TB per-file ceiling conflicts with the objects you actually create.

Choose Google Drive if...

Your files stay below 5 TB and Google Workspace collaboration, identity and document workflows matter more than having an uncapped per-file model.

For a single 3 TB object, Google Drive can be an excellent fit. For large migrations, account for the 750 GB-per-user 24-hour upload/copy policy rather than misdiagnosing it as a file-size error.

Choose iCloud Drive if...

Your priority is Apple ecosystem integration and your current workload has already been proven to work with the file sizes you use. Apple's current public upload guide does not give us a numeric maximum we can responsibly use for giant-file architecture planning.

Choose OneDrive if...

Your largest files stay under 250 GB and Microsoft 365/SharePoint integration is valuable. Above 250 GB per object, you need to split files or change the storage destination.

Choose pCloud if...

You are primarily solving a storage problem, not an office-suite problem, and your individual files can become extremely large. The strongest fit is the user who recognizes one or more of these patterns:

• video masters keep getting larger;
• VM or disk images are already hundreds of gigabytes;
• archives are retained for years rather than actively co-edited;
• splitting large objects adds unwanted restore complexity;
• you want the same storage account to remain usable even if individual files grow beyond today's 250 GB, 2 TB or 5 TB thresholds.

If that description sounds familiar, the unfinished decision is not whether pCloud accepts the object. Its current documentation says it does, provided the object fits your storage. The remaining decision is how much account capacity you need around that file.

Check current pCloud capacity options before choosing the workflow: Compare pCloud Plans & Pricing → Affiliate link. The relevant question here is capacity, not simply the existence of a no-per-file-limit rule.

Do not buy a plan exactly equal to your largest object

A 2 TB account for a 1.9 TB master looks efficient only on a spreadsheet. It leaves almost no room for:

• another version;
• temporary overlap during replacement;
• supporting files;
• future growth;
• recovery/version history overhead where applicable.

For long-term archive users, plan size should reflect the archive trajectory, not only today's biggest file.

If the storage need is stable and long-lived, our pCloud Lifetime break-even analysis covers the separate cost question. Do not reverse that order: first confirm pCloud fits the workflow, then decide whether annual or Lifetime billing makes sense.

What not to do after a huge upload fails

Do not immediately compress or split the file

First identify whether the failure came from a hard per-file maximum, browser transport, account quota, daily transfer policy or network interruption. Splitting a file does nothing for an account that is simply out of storage.

Do not assume browser failure equals provider failure

Dropbox is the clearest example. The service supports files up to 2 TB, but Dropbox itself recommends a different transport for giant uploads.

Do not quote old iCloud limits as current without checking

The old 50 GB number may still be operationally relevant in some contexts, but Apple's current public iCloud Drive upload page we verified in August 2026 does not state it. A current technical article should say that rather than laundering an old FAQ into a 2026 fact.

Do not assume "no file-size limit" means no local disk usage

If you access or edit a giant file through a virtual-drive system, caching and application behavior can still consume local storage. pCloud's no-per-file-cap claim and pCloud Drive's cache behavior are separate technical questions.

Do not let the cloud be the only copy of an irreplaceable master

A cloud provider is an availability and storage layer. It is not automatically a complete backup architecture. Keep an independent copy for data that would be expensive or impossible to recreate.

The technical verdict

For ordinary users, file-size limits are mostly invisible. For people handling disk images, raw video, VM images, large archives and scientific datasets, they become a platform decision.

The current verified hierarchy is unusually clear:

• OneDrive: 250 GB per file.
• Dropbox: 2 TB per file, with lower browser practicality.
• Google Drive: 5 TB per ordinary file, with a separate 750 GB/24-hour Workspace upload-and-copy policy.
• iCloud Drive: Apple's current public upload documentation does not state a numeric per-file maximum, so CloudScope leaves the number unverified rather than repeating stale guidance.
• pCloud: no published per-file upload restriction; the object must fit the account's available storage.

That does not make pCloud the universal winner. Google Drive remains extremely capable for multi-terabyte files, Dropbox remains excellent below 2 TB, OneDrive remains rational inside Microsoft-heavy workflows, and iCloud remains the natural choice for many Apple-centric users.

But if the recurring problem is "my archive keeps producing files that are too large for the platform", pCloud has the cleanest structural answer of the five: stop making the storage provider's per-file ceiling part of your workflow.

The final step is capacity. A no-limit upload rule is only useful when the plan has enough space for the object and the archive that comes after it.

See the current pCloud storage tiers and choose capacity around your real largest file: View pCloud Plans & Pricing → Affiliate link · Opens pCloud's plans page. Prices and plan capacities can change.

Sources and verification

CloudScope checked these primary sources on 21 August 2026:

1. Dropbox Help — What is the Dropbox file size limit?

https://help.dropbox.com/sync/upload-limitations

1. Dropbox Help — Uploading to Dropbox: how to add files and folders

https://help.dropbox.com/create-upload/add-files

1. Google Drive Help — Files you can store in Google Drive

https://support.google.com/drive/answer/37603

1. Google Workspace Admin Help — Storage and upload limits for Google Workspace

https://support.google.com/a/answer/172541

1. Apple iCloud User Guide — Upload and download files from iCloud Drive on iCloud.com

https://support.apple.com/guide/icloud/upload-and-download-files-mmad632d1df2/icloud

1. Apple iCloud User Guide — Set up iCloud Drive on all your devices

https://support.apple.com/guide/icloud/set-up-icloud-drive-mm203b05aec8/icloud

1. Microsoft Support — Restrictions and limitations in OneDrive and SharePoint

https://support.microsoft.com/en-us/onedrive/restrictions-and-limitations-in-onedrive-and-sharepoint

1. pCloud — Cloud Storage Pricing Plans

https://www.pcloud.com/cloud-storage-pricing-plans.html

1. pCloud Blog — From Gigabytes to Terabytes: How to Handle Large Files

https://blog.pcloud.com/from-gigabytes-to-terabytes-how-to-handle-large-files/

1. pCloud Help — Uploading, Downloading, and Organizing Files

https://help.pcloud.com/article/uploading-downloading-organizing

Editorial note on iCloud

Older Apple material historically published a 50 GB iCloud Drive file-size limit. The old support URL now redirects to Apple's current iCloud User Guide, where the numeric file-size statement is absent. We therefore do not present 50 GB as a verified current 2026 limit. If Apple republishes a numeric maximum, this article should be updated.

Internal-link plan for batch publish

Existing live links already used in this draft:

• /articles/pcloud-drive-cache-explained/
• /articles/backup-vs-cloud-storage/
• /articles/cloud-storage-vs-external-hard-drive/
• /articles/pcloud-lifetime-worth-it/
• /category/cloud-storage/ — suitable contextual link when converting draft to live article template
• /category/comparisons/ — suitable contextual link when converting draft to live article template

Suggested reverse links after batch deployment:

• pcloud-drive-cache-explained → link from the section discussing cache vs upload size
• pcloud-lifetime-worth-it → link from archive-capacity / long-term cost section
• cloud-storage-vs-external-hard-drive → link from large archive design section
• backup-vs-cloud-storage → link from the warning that one cloud copy is not a backup strategy

Cannibalization boundary

This page owns cross-provider maximum single-file upload/storage limits and the distinction between hard file cap, browser transport limit, account quota and daily transfer policy.

It must not absorb these separate intents:

• google-drive-750gb-upload-limit — Google-specific 24-hour transfer-limit troubleshooting;
• google-drive-streaming-uses-disk-space — Google Drive local cache/disk usage;
• pcloud-drive-cache-explained — pCloud cache architecture;
• backup-vs-cloud-storage — backup strategy;
• pcloud-lifetime-worth-it — pricing/break-even decision.