Every email attachment size limit you've ever hit was set by the receiving server, not the sending one. That's the detail that makes the problem so annoying: your provider accepts a 30 MB file quite happily, spends a minute pretending to send it, and then a bounce arrives hours later because the mail server at the other end refused it. You did nothing wrong and you still have to solve it.
This page covers what the real limits are, why they're lower than the numbers you see advertised, and the approach that stops the problem recurring rather than working around it once.
What the Email Attachment Size Limit Actually Is
There isn't one number, which is the root of the confusion. There are at least three, and the smallest one wins.
Your provider sets a cap on what it will accept from you. The recipient's provider sets a cap on what it will accept for them. And in between, encoding inflates the file: mail attachments are base64-encoded for transport, which adds roughly 33% to the size. A 20 MB file leaves your machine as about 27 MB of message, so an email attachment size limit of 25 MB rejects a file you'd have sworn was well under it.
The commonly quoted figures — 25 MB at Gmail, 20 MB at Outlook.com, 10 MB at plenty of corporate servers — are the post-encoding numbers. Work backwards through the 33% and the practical ceiling for a file is closer to 18 MB even when the stated limit is 25.
Corporate mail servers are frequently stricter still, and they don't advertise it. A recipient at a law firm or a bank may be behind a 10 MB gateway, which means an email attachment size limit you have no way of discovering until your message bounces.
Why Raising the Limit Isn't the Answer
The instinctive fix is to find a provider with a bigger number. It doesn't work, because the binding constraint is at the far end and you don't control it.
A provider advertising 50 MB attachments is telling you what it will accept, not what anyone will receive. Send that 50 MB message and it will be rejected by most of the internet. The larger number buys you almost nothing except a slower failure.
Zip compression rarely rescues it either. Photographs, video and PDFs are already compressed, so zipping them saves a few percent at best. Splitting an archive into parts works technically and is miserable for the recipient, and many gateways strip multi-part archives as suspicious anyway.
The Approach That Removes the Problem
What actually works is not attaching the file at all — sending a link to it instead, so the message stays small and the file travels over HTTP where nobody has an email attachment size limit.
That's a familiar workflow, and normally an annoying one: upload to a file service, wait, copy a link, paste it into the message, and remember to clean up later. The friction is why people keep trying to attach things instead.
On our webmail that step is automatic. Files under 18 MB attach normally, the way you'd expect. Anything larger is routed into Drive as you compose and inserted as a share link, without you deciding anything or leaving the composer. The recipient sees a link that downloads the file; you see a message that sends.
The Recipient's Side, and Yours
A link instead of an attachment changes the arrangement in ways that are mostly to your advantage.
The link is revocable. Sending the wrong file to the wrong person is ordinarily unfixable — the copy is in their mailbox forever. A share link can be revoked, and the download stops working. That alone is worth more than the size limit it solved.
Downloads are capped. Composer-created links carry a default ceiling of 100 downloads, which stops a forwarded link becoming an open distribution channel.
Your sent folder stays small. Attachments are stored twice, in your Sent copy as well as the recipient's inbox. A team emailing large files fills its storage quota with its own outbound history, and links remove that entirely.
You can see whether it was collected. An attachment tells you nothing after it leaves. A link tells you whether anyone downloaded it, which settles the "did you get it?" exchange without another email.
When You Should Still Attach the File
Links aren't universally better and it would be silly to pretend so.
Attach when the recipient needs the file to survive independently of you — contracts, invoices, anything that should still open in five years if the sender's account is gone. A revocable link is a liability in that situation rather than a feature.
Attach when the recipient's environment is hostile to links. Some corporate gateways rewrite or strip external URLs, and some recipients simply won't click one. Under an email attachment size limit of 10 MB with a file of 9 MB, attaching is the right call.
Attach for anything small enough not to be a question. The threshold exists so you don't have to think about files that were never going to be a problem.
Practical Ways to Get Under the Limit
Sometimes you need the file to be an attachment and it's slightly too large. In rough order of how much they help:
- Re-export the PDF. PDFs from design tools routinely embed full-resolution images. Exporting at screen resolution often cuts 80% with no visible difference for a document meant to be read.
- Resize photographs. A phone photo is 4 MB and nobody needs the original dimensions to look at it. Three resized images will clear an email attachment size limit that three originals won't.
- Send video as a link, always. Video is never getting under any limit worth discussing, and encoding makes it worse.
- Check for embedded fonts and revision history in office documents, which can double the file size invisibly.
Compressing is the last resort rather than the first, because it helps least on exactly the file types that cause the problem. None of these tricks changes the underlying email attachment size limit; they just get one particular file under it this once.
Why the Bounce Arrives So Late
One of the more infuriating parts of hitting an email attachment size limit is the delay. You send at nine, everything appears fine, and the failure notice arrives at half past eleven — by which time you've assumed the file was delivered and moved on.
That happens because acceptance and delivery are separate events. Your own server accepts the message immediately, because it has no way of knowing what the recipient's server will do with it. Only when it opens a connection to the far end, which may be queued behind other traffic, does the rejection come back. If the receiving server is temporarily unreachable, your server will retry patiently for hours before giving up, and the notice you eventually get may be about a message you sent yesterday.
The practical consequence is that no news is not good news when you're near an email attachment size limit. If a file matters and it was near the limit, the safe assumption is that you don't know it arrived until someone says so.
Attachments and Your Own Storage
The email attachment size limit is usually discussed as a sending problem, and it has a receiving side that's quieter and more expensive over time.
Every attachment anyone sends you is stored in your mailbox, and every one you send is stored again in Sent. A team that habitually mails documents back and forth is storing the same file many times over — once per recipient's mailbox, once per sender's Sent folder, and once more each time somebody forwards it with the attachment intact.
This is the usual reason a mailbox quota fills without anyone doing anything unusual, and it's why the email attachment size limit is worth solving as a habit rather than per message. The mail itself is trivial; the attachments are almost all of it. Moving to links rather than attachments for anything substantial removes the duplication at both ends, which is a storage benefit rather than a delivery one and tends to be the reason teams keep the habit after the original problem is solved.
Where the Files Live Afterwards
Files routed out of the composer land in Drive, which is part of the same account as the mail rather than a separate service with its own login and its own invoice. Storage starts at 250 GB for $3.20 a month on a slider, and the mechanics of the links themselves are covered in how share links work.
That matters for the recurring version of this problem. Somebody who hits an email attachment size limit once needs a workaround; somebody who hits it weekly needs the workaround to be the default path, with the files organized somewhere they can be found again, shared with a colleague, or mounted as a drive — which is what WebDAV access is for.
The short version: stop trying to find a bigger number, because the number that stops you belongs to somebody else. Send the link, keep the ability to revoke it, and let the threshold decide.
