Almost everyone has hit the wall: you attach a video, a design file, or a folder of photos to an email, click send, and get a bounce saying the message is too large. Email was designed decades ago for short text messages, not for moving gigabytes of data, and the attachment limits reflect that history. Knowing the actual numbers helps you plan around them.
Gmail allows attachments up to 25 MB per message. If you try to attach something larger, Gmail intercepts it and offers to upload the file to Google Drive and insert a link instead — which is a workaround, not a true email attachment, and it requires the recipient to have access to that Drive file. It is also worth noting that the 25 MB is the total size of the whole message, so several smaller files can add up to the limit together.
Outlook.com and Microsoft 365 are more conservative. For consumer Outlook.com accounts the practical limit is around 20 MB, and while some corporate Exchange configurations can be raised as high as 150 MB by an administrator, you should not count on that unless your IT department has told you so. Assume roughly 20 MB and you will rarely be surprised by a bounce.
Yahoo Mail matches Gmail at 25 MB per message. Apple’s iCloud Mail is a little tighter at 20 MB. Apple does offer a clever escape hatch called Mail Drop: when your attachment is too big, iCloud uploads it to Apple’s servers and replaces it with a download link, supporting files up to 5 GB. Mail Drop is convenient, but it is a temporary cloud upload with an expiry, not a direct transfer, and it is only wired into Apple’s own Mail app.
So why are these limits so low when we routinely stream 4K video and download huge games? The answer is partly the age of the email protocol and partly the economics of how mail is stored. Every message sits on the provider’s servers, often duplicated into the sender’s Sent folder and the recipient’s Inbox, and sometimes scanned and backed up on top of that. A single large attachment can become several copies across the system, so providers keep the ceiling low to control storage costs at the scale of billions of accounts.
There is also a sneaky technical tax that makes the real numbers worse than they look. Email cannot carry raw binary data, so attachments are encoded into plain text using a scheme called Base64. Base64 represents every three bytes of a file using four text characters, which inflates the size by roughly 33 percent. That means a file which is 20 MB on your disk becomes about 27 MB once it is encoded for email — so a ‘25 MB limit’ can reject a file that your computer reports as only 19 or 20 MB. This is why attachments fail at sizes that seem to be under the cap.
The common workarounds all involve stepping outside email itself. Google Drive, Dropbox, WeTransfer, and iCloud Mail Drop each take the same basic approach: upload your file to a server, generate a link, and send the link instead of the file. This works, but it means your data now sits on a third-party server, sometimes for days or weeks, subject to that provider’s retention, scanning, and access policies. For sensitive material — contracts, medical records, unreleased work — that is a real consideration, not a hypothetical one.
A peer-to-peer transfer avoids the whole problem in a different way. Instead of uploading your file to a server and mailing a link, it opens a direct, encrypted connection between your browser and the recipient’s browser and streams the file straight across. There is no attachment to encode, no mailbox to overflow, and no copy left on anyone’s server. Because nothing is stored, there is no meaningful size limit — sending a 30 MB file and sending a 30 GB file work the same way.
With BigFileDrop the flow is straightforward: open the site, pick your files, and share the short code or link with the other person through whatever channel you already use, including email. They open it, accept, and the transfer runs directly between the two browsers, encrypted end to end. You are still using email to coordinate — you are just not asking it to carry the payload it was never built to carry.
The one trade-off to keep in mind is that a live P2P transfer is like a phone call: both browser tabs need to stay open until it finishes, because the file is flowing between the two devices rather than sitting in a mailbox waiting to be picked up later. For that you get no size limit, no third-party storage, and no Base64 penalty quietly eating into your allowance. When email says a file is too big, that is usually your cue that a direct transfer is the better tool for the job.