{"id":3034,"date":"2026-07-21T09:27:26","date_gmt":"2026-07-21T09:27:26","guid":{"rendered":"https:\/\/fileflap.net/blog\/?p=3034"},"modified":"2026-07-25T09:36:17","modified_gmt":"2026-07-25T09:36:17","slug":"email-attachment-size-limits","status":"publish","type":"post","link":"https:\/\/fileflap.net/blog\/email-attachment-size-limits\/","title":{"rendered":"Email Attachment Size Limits: Gmail, Outlook & More (2026)"},"content":{"rendered":"\n

Every major email provider limits how large an attachment can be, and the limit is usually smaller than people expect \u2014 often just 20\u201325MB, well below the size of a short screen recording, a folder of high-resolution photos, or a single design file.<\/p>\n\n\n\n

The limit isn’t really about the provider being strict. Email was never built to move large binary files efficiently. Attachments have to be converted into a text-safe format before they can travel through the same system that delivers plain-text messages, and that conversion inflates the file’s effective size before it ever reaches the recipient’s inbox.<\/p>\n\n\n\n

This guide covers the current limit for every major provider, why the limits exist in the first place, what actually happens when a file is too big, and the most reliable ways around the problem, so you can send large files online<\/a> without issues.<\/p>\n\n\n\n

Email attachment size limit by provider<\/h3>\n\n\n\n
Provider<\/th>Max attachment size<\/th>Notes<\/th><\/tr><\/thead>
Gmail<\/td>25MB<\/td>Larger files auto-convert to a Google Drive link<\/td><\/tr>
Outlook.com \/ Microsoft 365<\/td>20MB (up to 150MB on some enterprise\/Exchange configurations)<\/td>Varies significantly by admin policy<\/td><\/tr>
Yahoo Mail<\/td>25MB<\/td>Hard limit, no auto-conversion to a link<\/td><\/tr>
iCloud Mail<\/td>20MB natively (up to 5GB via Mail Drop)<\/td>Mail Drop uploads the file separately and inserts a link<\/td><\/tr>
ProtonMail<\/td>25MB<\/td>Combined across all attachments in one message<\/td><\/tr>
Zoho Mail<\/td>20MB (up to 250MB via Zoho WorkDrive links on paid plans)<\/td>Free vs. paid tiers differ substantially<\/td><\/tr>
AOL Mail<\/td>25MB<\/td>Similar architecture to Yahoo<\/td><\/tr>
GMX \/ Mail.com<\/td>50MB<\/td>Higher than most mainstream providers<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Limits change periodically and can also be reduced further by a company’s internal mail server, even when the provider’s stated cap is technically higher. If a colleague can’t open a file that falls within the limits above, an internal IT policy \u2014 not the public provider limit \u2014 is a common cause.<\/p>\n\n\n\n

Why does every provider limit attachment size?<\/h3>\n\n\n\n

Three overlapping reasons explain why virtually no mainstream provider allows large attachments, even ones with generous overall mailbox storage.<\/p>\n\n\n\n

Encoding overhead<\/h4>\n\n\n\n

Email attachments are converted into a text-safe format called Base64 before they’re sent, because the underlying email protocol (SMTP) was designed to carry plain text, not raw binary data. Base64 encoding increases the effective size of a file by roughly 33%. A file that’s 20MB on disk becomes closer to 27MB in transit, which is one reason providers set their limits somewhat below a round number.<\/p>\n\n\n\n

Storage and delivery costs<\/h4>\n\n\n\n

Every attachment is stored in the sender’s “Sent” folder and separately in each recipient’s inbox. Send the same 20MB file to ten people, and depending on the provider’s architecture, that can mean roughly 200MB of duplicated storage across all the mailboxes involved. Multiply that across billions of users, and attachment size limits become a straightforward infrastructure cost issue for the provider.<\/p>\n\n\n\n

Spam and malware scanning<\/h4>\n\n\n\n

Large or unusual attachments are more expensive to scan quickly for malicious content. Many mail servers \u2014 both consumer providers and corporate IT systems \u2014 apply stricter filtering or outright rejection to attachments above a certain size specifically because they’re harder to evaluate at scale within the delivery window users expect.<\/p>\n\n\n\n

What happens when a file is too large to email<\/h3>\n\n\n\n

The exact failure mode depends on the provider and, sometimes, on which email client is used to send the message, though you can definitely send large files without email<\/a> if you want that, even with resumable uploads<\/a>.<\/p>\n\n\n\n

Gmail<\/strong> automatically detects when an attachment exceeds 25MB and uploads it to Google Drive instead, inserting a shareable Drive link into the message body. This happens transparently in Gmail’s web and mobile interface, but the recipient will need appropriate Drive permissions to open it, and the behavior doesn’t apply if you’re sending through a third-party client connected to a Gmail account.<\/p>\n\n\n\n

Outlook<\/strong> typically blocks the send before the message leaves the outbox, returning an error that names the size limit. Some configurations instead deliver a bounce-back (non-delivery report) after the send appears to succeed, which can be more confusing since the sender may not notice for several minutes.<\/p>\n\n\n\n

Yahoo, AOL and most other consumer providers<\/strong> reject the message outright at send time, often with a generic error that doesn’t clearly state the size problem \u2014 leading many users to assume something else is wrong.<\/p>\n\n\n\n

Corporate\/Exchange environments<\/strong> frequently apply a lower limit than the provider’s public number, set by the organization’s IT department, and may reject the message with an error that references internal policy rather than the provider’s own documentation.<\/p>\n\n\n\n

Why 25MB feels arbitrary but usually isn’t<\/h3>\n\n\n\n

The most common limits \u2014 20MB, 25MB \u2014 line up closely with what mail servers could reliably process quickly at the time these ceilings were established, adjusted for the Base64 overhead described above. Even as storage has become cheap and bandwidth has increased dramatically, these numbers have stayed roughly the same for over a decade across most providers, because the underlying constraint (SMTP’s text-based design and per-mailbox duplication) hasn’t changed.<\/p>\n\n\n\n

This is why increasing your own mailbox storage plan, or paying for a premium email tier, almost never raises your attachment limit. Storage and attachment size are separate constraints.<\/p>\n\n\n\n

How to send a file that’s too large for email<\/h3>\n\n\n\n

Use a dedicated file-transfer link.<\/strong> Upload the file once, then share a link instead of an attachment. This avoids provider size caps entirely, avoids the per-recipient duplication problem, and lets the recipient download at their own pace instead of waiting for a large message to fully arrive.<\/p>\n\n\n\n

Compress the file first<\/strong>, if the content type allows meaningful size reduction. This sometimes gets a file just under the limit, though it’s a partial fix at best for anything over a few hundred MB \u2014 see the compression breakdown below.<\/p>\n\n\n\n

Use cloud storage sharing<\/strong> (Google Drive, Dropbox, OneDrive) if both sender and recipient already use the same platform. This works well for ongoing collaboration but usually requires the recipient to have or create an account, and permissions can be a common source of “I can’t open this” follow-up messages.<\/p>\n\n\n\n

Split the file into multiple parts<\/strong> using archive software, though this pushes the size problem onto the recipient, who then has to download every part correctly and reassemble them \u2014 a common source of corrupted or incomplete files if even one part fails to transfer.<\/p>\n\n\n\n

For anything over a few hundred MB \u2014 video, datasets, design files, backups, photo libraries \u2014 a transfer link is almost always faster to set up and more reliable to receive than working around email’s limits with file compression<\/a> or splitting.<\/p>\n\n\n\n

Does compressing a file actually help you email it?<\/h3>\n\n\n\n

Sometimes, but not reliably for the file types people most often try to email.<\/p>\n\n\n\n

Compresses well:<\/strong> Documents (Word, PowerPoint, plain text), uncompressed images (BMP, TIFF, some RAW formats), spreadsheets with large amounts of repeated data, and some structured datasets (CSV, JSON, XML) can shrink substantially \u2014 often 50% or more \u2014 when zipped.<\/p>\n\n\n\n

Compresses poorly:<\/strong> Video files (MP4, MOV), photos already saved as JPEG, music files (MP3), and any file that’s already an archive (ZIP, RAR) shrink very little, because the data is already compressed. Zipping them again typically saves only a few percent, and can occasionally make the file slightly larger due to archive overhead.<\/p>\n\n\n\n

For a large video file specifically, compression is rarely a real fix \u2014 it either meaningfully degrades quality to hit a smaller size, or barely reduces the file at all if you re-encode conservatively. A transfer link avoids that tradeoff entirely.<\/p>\n\n\n\n

Email attachment limits vs. file-transfer services<\/h3>\n\n\n\n
<\/th>Email attachment<\/th>File-transfer link (FileFlap)<\/th><\/tr><\/thead>
Typical max size<\/td>20\u201325MB<\/td>Up to 1TB per file<\/td><\/tr>
Delivery method<\/td>File travels inside the message<\/td>Recipient downloads via link<\/td><\/tr>
Multiple recipients<\/td>File duplicated per mailbox<\/td>One link, unlimited downloads<\/td><\/tr>
Expiration control<\/td>None<\/td>Time-based or download-count based<\/td><\/tr>
Password protection<\/td>Not native<\/td>Built in<\/td><\/tr>
Recipient requirements<\/td>None beyond an inbox<\/td>None \u2014 no account required<\/td><\/tr>
Failure mode on large files<\/td>Blocked, bounced, or silently converted<\/td>N\/A \u2014 no comparable ceiling<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

A quick decision guide<\/h3>\n\n\n\n

File under 20MB, going to one or two people.<\/strong> A standard email attachment is fine \u2014 no need to overthink it.<\/p>\n\n\n\n

File between 20MB and a few hundred MB, sent occasionally.<\/strong> Compression may get documents or images under the limit. For video or already-compressed files, skip straight to a transfer link.<\/p>\n\n\n\n

File in the multi-GB range, or sent regularly (weekly deliverables, client work, backups).<\/strong> A file-transfer service is the more reliable long-term habit \u2014 it removes the “will this go through” uncertainty entirely and gives you expiration and password controls email doesn’t offer.<\/p>\n\n\n\n

Sensitive file of any size.<\/strong> Consider a password-protected, expiring link regardless of size, since email attachments have no equivalent access control once they land in someone’s inbox.<\/p>\n\n\n\n

Internal link: Link “password-protect a file before sending” to \/blog\/password-protect-expiring-file-links\/.<\/p>\n\n\n\n

Why “just increase the limit” isn’t something providers will do<\/h3>\n\n\n\n

It’s a reasonable question: if storage and bandwidth are both cheap now, why hasn’t Gmail simply raised its 25MB cap? A few structural reasons:<\/p>\n\n\n\n