The short answer
For storing and sharing multi-gigabyte files without a host that can read them, beebeeb is the strongest pick: it streams files through chunked AES-256-GCM in the browser, so a 40 GB video encrypts without ever loading the whole thing into RAM, and the server only sees ciphertext. Need to send one big file once? A transfer tool is simpler. Need a host that genuinely can't decrypt it? The field gets short fast.
Why do large files break most cloud storage?
Two limits bite when files get big, and they are not the same limit.
The first is the per-file cap. Dropbox tops out at 350 GB for a browser upload (uploads near and above that start timing out) and steers you to the desktop app for anything larger, where the ceiling is 2 TB. Google Drive allows files up to 5 TB but enforces a 750 GB daily upload limit across your whole account, so one heavy export day can stall you until the clock resets. Internxt Drive caps a web upload at 40 GB. WeTransfer's paid Ultimate plan caps a single transfer at 200 GB no matter what you spend.
The second limit is quieter and matters more for privacy: most browser-based clients cannot encrypt a file they cannot hold in memory. The naive way to do client-side encryption is to read the entire file, call the browser's crypto API once, and upload the result. That works for a 10 MB PDF and dies on a 10 GB render — the tab runs out of memory. So a lot of "encrypted" services quietly skip client-side encryption for large files, or never offered it. The encryption then happens on their server, after they have already received your plaintext. "Encrypted" becomes a marketing checkbox rather than an engineering property. That gap is what the rest of this post is about.
How does beebeeb handle files bigger than RAM?
beebeeb encrypts large files by streaming them in chunks. Each chunk gets its own nonce, is sealed and authenticated with AES-256-GCM, and is uploaded before the next chunk is read, so the full file never sits in memory at once. The work runs in a Web Worker, so the tab stays responsive while a multi-gigabyte upload grinds through. Your file key is derived on-device with Argon2id (256 MiB memory cost) and never leaves the browser. The server in Falkenstein, Germany receives a sequence of encrypted blocks and stores them; it cannot reassemble or read the file.
You can check that claim instead of trusting it, because the product clients are open source — the streaming crypto is the same Rust core compiled to WASM in the browser and run natively by the bb CLI. (The server and this marketing site stay private; the auditable trust signal is the client code.) Storage scales to 99 TB self-serve at €10.99 per extra TB, with a custom quote beyond that. Not "unlimited" — nobody actually runs unlimited storage, they just decline to tell you where the ceiling is. Ours is 99 TB before you have to call us.
The honest limits: native desktop and mobile apps are coming soon, so today the surfaces are the web app and the bb CLI (which also speaks WebDAV). And zero-knowledge encryption means that if you lose your password and your BIP39 recovery phrase, we cannot get your files back. That is the trade for a host that genuinely can't read them.
What about just sending one big file?
Storing and sending are different jobs, and the right tool depends on which one you are doing.
If you need to fire a 4 GB cut off to a client once and never think about it again, a transfer service is the right shape. WeTransfer free now runs on a monthly quota — a single transfer up to 3 GB, capped at roughly 10 sends or 3 GB combined every 30 days, expiring after 3 days. The Ultimate plan (€19/mo) raises that to 200 GB per transfer with 1 TB of storage. Fast and frictionless. It is also not zero-knowledge: WeTransfer can read what passes through it, and the link is the only access control.
Internxt Send is the privacy-minded version of the same idea — encrypted transfers with no account required. Worth knowing if your concern is a host reading a one-off send rather than building a storage home.
beebeeb covers the send case too, but differently: encrypted share links with an expiry date, an optional passphrase, and revocation, plus accountless file requests so someone can upload to you without signing up and without the server reading the result. Storage and intake in one place, instead of a separate transfer tool bolted on.
The large-file field, compared honestly
Per-file caps, whether the host can read your file, and where it lives. The numbers below were checked in 2026 and move occasionally — verify before you commit budget.
| Provider | Per-file cap | Zero-knowledge? | Notes |
|---|---|---|---|
| beebeeb | No fixed cap (streamed) | Yes, every tier incl. Free | Streaming AES-256-GCM; web + CLI today; Falkenstein, Germany |
| MEGA | No hard cap | Yes (E2E) | Free downloads throttled (~1 GB / 6 h); up to 16 TB tiers |
| Internxt | 40 GB (web Drive) | Yes | Open-source clients; Internxt Send for transfers |
| Sync.com | No published cap | Yes (AES-256 + RSA-2048) | Large web uploads steered to the desktop client |
| pCloud | No file-size limit | Only with paid Crypto add-on | Standard files are not zero-knowledge by default |
| Dropbox | 350 GB web / 2 TB app | No (holds keys) | US/Cloud Act exposure; ~3 TB plan ceiling |
| Google Drive | 5 TB, 750 GB/day cap | No | Convenient if you already live in Workspace |
| WeTransfer | 200 GB/transfer (paid) | No | Transfer tool, not a storage home |
A few fair concessions. MEGA is genuinely zero-knowledge and handles enormous files; the catch is on the free tier, where downloads get throttled to roughly 1 GB per six hours, which makes pulling a big file back out painful. pCloud imposes no file-size limit and is pleasant to use, but its zero-knowledge layer (pCloud Crypto) is a paid extra — by default pCloud can read your files, so don't read "no size limit" as "private." Sync.com is properly zero-knowledge with no published file ceiling, but its browser uploader struggles on very large files and pushes you to the desktop app. Dropbox and Google Drive win on convenience and ecosystem fit, and if your threat model doesn't include the provider, a court order, or a breach reading the file, they are fine. They hold the keys, though, and a breach of a key-holding host leaks readable files.
How to actually pick
It comes down to one question: does the host need to be unable to read the file?
- Yes, and you want a storage home with sharing and intake: beebeeb, MEGA, Sync.com, or Internxt. Among these, beebeeb is the one with open-source clients, streaming encryption that doesn't choke on files bigger than RAM, a CLI for scripting big uploads, and EU incorporation with storage in Germany.
- Yes, but it's a one-off send: Internxt Send, or a beebeeb expiring share link if you also want the file kept.
- No, convenience wins: Dropbox or Google Drive — just price in the daily caps (Google's 750 GB/day) and the per-file ceilings before assuming the cloud will take whatever you throw at it.
For reference, raw object storage like AWS S3 runs about $0.023 per GB-month before you have built any of the client-side encryption, sharing, or recovery a person actually needs — that's its own post. The point here is narrower: large files expose which providers really encrypt before upload and which only say they do.
beebeeb's free tier is 5 GB, zero-knowledge like every paid tier and with no device cap — enough to push a real video through the streaming encryptor and watch a multi-gigabyte file leave as ciphertext before you commit. The paid plans start at €10.99/mo for 1 TB and scale per-TB from there. Try a big upload first; the architecture is easier to trust once you have watched it work.