How to Send Large Files When Email and Cloud Storage Won't Work
A practical walkthrough for the moment your file gets bounced back — why it happened, what your real options are, and how to fix a connection that won't go through.
Why the Upload Failed
Every attachment and upload service enforces a size cap, and they're smaller than most people expect until they hit one:
- Gmail — 25 MB per message, attachments included
- Outlook / Microsoft 365 — 20 MB per message by default
- WeTransfer (free) — 2 GB per transfer
- Slack (free workspace) — 1 GB total file storage for the workspace, not per file
- Discord (no Nitro) — 25 MB per file, better between servers with boosts
A single 4K video export, a RAW photo batch, a compiled build artifact, or a database dump can blow past every one of these without being an unusually large file by 2026 standards. The limit isn't a bug in your workflow — it's a deliberate business decision by each provider, tied to their storage and bandwidth costs.
Three Real Options, and Their Honest Tradeoffs
Works for some formats, not others
Zipping a folder of documents, spreadsheets, or uncompressed images can shrink it dramatically. It does almost nothing for formats that are already compressed — video (MP4, MOV), most photo formats (JPEG), and archives (ZIP itself, installers). If your file is already a video export or a RAW photo set, compression will save you single-digit percentages at best.
Reliable, but slow and often paid
Uploading to Google Drive, Dropbox, or a paid transfer service works for files up to their plan limit, and the recipient can download whenever they're ready. The cost is time — the file has to fully upload before anyone can download it — and, past the free tier, money.
No size limit, but both sides need to be online
A WebRTC-based tool like StreamSnatcher connects two browsers directly. There's no provider-imposed size cap because the file never touches a server to be stored — it streams straight from one device to the other. The tradeoff: both the sender and the recipient need their browser tab open at the same time, since there's no server holding the file for later pickup.
For a full breakdown of when each approach wins, see our comparison of P2P vs. cloud storage.
Sending a Large File Peer-to-Peer: Step by Step
- Open StreamSnatcher and click "Start Transfer." A session link and QR code are generated instantly — no account, no upload starts yet.
- Send the link or QR code to the recipient through whatever channel is convenient — chat, email, text message. It's just a link; it carries no file data.
- Wait for the recipient to open the link. Their browser and yours negotiate a direct, encrypted connection automatically.
- Drag the file onto the transfer zone. It begins streaming immediately — there is no "upload" phase before the recipient can start receiving.
- Keep both tabs open until the transfer completes. Closing the tab ends the session, since nothing is stored for either side to resume from later.
When the Connection Won't Establish
Occasionally two browsers can't find a direct path to each other. This isn't random — it has a specific, explainable cause almost every time.
Restrictive NAT or firewall
WebRTC uses a negotiation process called ICE to find a working network path, trying several candidate routes in order: direct local-network paths, then your public IP address (discovered via a STUN server), and finally a relay server if neither works. Corporate networks, carrier-grade NAT on some mobile connections, and certain firewalls block the direct paths entirely, forcing the connection to fall back to a relay.
The relay fallback handles most of these
A properly configured WebRTC app — including StreamSnatcher — automatically falls back to a TURN relay server when a direct connection can't be established. You shouldn't need to do anything; the transfer just takes the relay path instead of a direct one. It's slightly slower than a direct connection, but still works.
Something is blocking all outbound UDP/TCP on the relevant ports
If the connection still won't complete even with a relay available, the most common remaining cause is a network that blocks the relay's ports outright — some corporate and public Wi-Fi networks do this deliberately. Trying a different network (mobile data instead of office Wi-Fi, for example) resolves this in the large majority of remaining cases.
Real Scenarios Where Size Limits Bite
- Video editors handing off a raw or exported 4K project file to a client or collaborator — routinely tens of gigabytes.
- Developers sharing a compiled build, container image, or VM snapshot for testing on another machine.
- Photographers delivering a full RAW shoot instead of a compressed preview gallery.
- Anyone moving a database export or backup between a workstation and a server, or between two personal devices, without provisioning cloud storage for a one-time transfer.
Conclusion
Attachment and upload limits are a policy choice by each provider, not a hard technical ceiling on how large a file can be sent. When a file is too big to email or too inconvenient to justify a paid cloud plan, a direct peer-to-peer transfer removes the size question entirely — the only real requirement is that both people are online for the length of the transfer.
Start a transfer now — there's no size limit, no account, and no upload wait.