Attachment Too Large to Send: Limits and What to Do

When you try to send an email and get an 'attachment too large to send' error, the number at fault is almost never the one you saw in your file manager. Email servers apply their limits to the full encoded message, not the raw file, and encoding inflates that size by roughly a third before the message touches any server. A 22 MB PDF can become a 29 MB message, and that is before the second limit — the one on the recipient's server — gets any say.

This guide explains why the file size on disk differs from the size the server measures, maps the four common causes of attachment rejection to their fixes, and gives you three ranked alternatives to attaching large files directly.

What does 'attachment too large to send' actually mean?#

The error appears under several names. Gmail may show 'Attachment size exceeds the allowable limit.' Exchange-based accounts return SMTP code 552 5.3.4 — 'message size exceeds fixed maximum message size.' Some clients show a generic 'Request Entity Too Large.' The phrasing differs; the cause is the same.

When your email client attaches a file, it converts the binary data into base64 text encoding as part of the MIME standard (RFC 2045). Base64 is safe to transmit as plain text but carries overhead: every three bytes of raw data become four bytes of encoded text — a size increase of roughly 33–37%. A file that is 20 MB on disk arrives at the sending server as a message closer to 27 MB, before email headers add a small amount more.

The second complication is that limits apply at both ends of the delivery path. Your sending server governs what your client may transmit. The recipient's mail server — whether Exchange Online, Yahoo, ProtonMail, or a self-hosted SMTP instance — applies its own limit when accepting the inbound message. A message that clears your server's outgoing check can still bounce off the recipient's. The binding limit is whichever is smaller.

As of mid-2026, Gmail's outgoing limit is 25 MB per message. Outlook.com personal accounts cap at 20 MB. Exchange Online defaults to 25 MB, though administrators can raise this to 150 MB for their organization. Verify current figures on each provider's help pages, as these numbers change.

What causes the 'attachment too large' error?#

The error has four distinct causes. Knowing which one applies before you start resizing and resending saves you a round-trip bounce cycle.

Fix 1: Share via a cloud link#

The most reliable fix for any large attachment is to not attach the file at all. Upload it to a cloud storage service and paste the sharing link into the email body. The recipient clicks to download directly from the storage service, the mail servers never handle the file, and size limits become irrelevant.

The steps are the same across Google Drive, Dropbox, and OneDrive:

1. 1

   Upload the file to your cloud storage service

   Drag the file into Google Drive, Dropbox, OneDrive, or a similar service. Wait for the upload to finish before creating the link.

2. 2

   Create a sharing link with the right permissions

   Open the share menu and create a link. For a one-way share, 'anyone with the link can view' is sufficient. If the recipient needs to edit or comment, set the permission accordingly before copying.

3. 3

   Paste the link into the email body

   Paste the sharing link where the attachment would have appeared. Mention the file name and approximate size in the message so the recipient knows what they are opening before they click.

4. 4

   Set a link expiry for sensitive files

   Google Drive, Dropbox, and OneDrive Business all support link expiry. For anything confidential, set the link to expire after one to two weeks rather than leaving it permanently open.

Fix 2: Compress the file before attaching#

Compression works when the file is close to but not far over the limit, and only on file types that have not already been compressed. Microsoft Office documents (.docx, .xlsx, .pptx), plain-text files, CSV exports, and mixed folders compress well and can shrink 30–70%. JPEG, PNG, MP4, PDF, and existing ZIP files are already compressed internally and typically shrink by only 1–3% — not enough to matter.

Steps on any platform:

1. 1

   Compress the file

   On macOS, right-click in Finder and select Compress. On Windows, right-click and choose Send to > Compressed (zipped) folder. For more control over format and split size, 7-Zip on Windows and Linux is free and widely used.

2. 2

   Check the compressed size against the adjusted ceiling

   If your server limit is 25 MB, the resulting ZIP must be under approximately 18 MB to survive base64 encoding in transit. Check the ZIP size against that adjusted figure, not the server's raw stated limit.

3. 3

   For images, reduce resolution before compressing

   High-resolution images often lose 40–70% of their size with minimal visible quality change when exported at a lower resolution or run through a tool like Squoosh or TinyPNG before you compress the folder.

4. 4

   If the compressed file is still too large, move to Fix 1 or Fix 3

   Compression has a ceiling. A 60 MB PDF will not become a 15 MB ZIP. If the format is already compressed or the savings are insufficient, use a cloud link or a transfer service instead.

Fix 3: Split the file or use a dedicated transfer service#

When compression is not enough and the recipient cannot access a cloud storage service from their network, two other approaches work.

Splitting with 7-Zip breaks one large file into smaller archive parts. The recipient reassembles them with 7-Zip or any compatible tool. This is practical for large source-code exports or design packages, but requires the recipient to have an unpacking tool and to receive every part in full.

1. 1

   Install 7-Zip and right-click the file

   Select 7-Zip > Add to archive from the context menu.

2. 2

   Set a part size that accounts for encoding overhead

   In the 'Split to volumes, bytes' field, enter a value that leaves headroom after base64 inflation. For a 25 MB server limit, entering 15m creates 15 MB parts that clear the limit with room to spare.

3. 3

   Send each part in a separate email

   Include the part number and total in the subject line — for example, 'Project files — Part 1 of 3' — so the recipient knows to wait for all parts before unpacking.

The simpler alternative is a dedicated file-transfer service. WeTransfer's free plan supports transfers up to 2 GB; the recipient gets a download link that expires after seven days. Smash and Filemail offer similar flows. These services bypass the mail-server size limit entirely — you upload once, they send the recipient a download link, and no file ever transits a mail server. Unlike splitting, the recipient needs no special software and you send a single link in one email.

How to tell which cause you have#

The quickest diagnostic is to look at where the error appears and what the message says.

If the error appears immediately inside your email client before you click Send, the client is enforcing a limit it already knows about from the server. Check the raw file size. If it is above approximately 18 MB on a 25 MB server, or above roughly 14 MB on a 20 MB server, the file itself is over the effective ceiling. Fix 1 or Fix 2 applies.

If the message appears to send but a non-delivery report arrives in your inbox a few minutes later, read the error text in the bounce carefully. A bounce that names your own sending domain or your sending server's hostname means the outbound limit rejected it — Fix 2 or Fix 1 applies. A bounce that cites a different hostname or the recipient's mail server domain means the recipient's inbound limit rejected it. In that case, Fix 2 will not help because the size problem is at the other end; only Fix 1 or Fix 3 bypasses it.

If the message delivers without error but the recipient cannot open the attachment, the issue is not size — it is a blocked file type, which is a separate problem unrelated to message size.

How to prevent attachment size errors#

The most durable fix is to make cloud links your default for any file over 10 MB. This sidesteps both the sending limit and the encoding overhead entirely. The recipient can access the latest version even if you update the file after sending, and neither inbox accumulates large attachments.

For recurring sends — weekly reports, design reviews, contract packs — store files in a shared cloud folder and email the folder link rather than re-attaching updated versions. Future versions appear at the same link with no new message required.

Know your effective ceiling before you attach. For a 25 MB server limit, the safe maximum file size after accounting for encoding overhead is roughly 18 MB. For a 20 MB limit, roughly 14 MB. If a file is within 3–4 MB of that ceiling, send it as a link rather than risk a bounce.

The recurring cost of attachment errors is not the bounce itself but the interrupt: the new draft, the file-handling decisions, the resend, and the follow-up to confirm delivery. [We build AI Emaily](/), an AI-native email client for Gmail, Outlook, and IMAP, built to reduce exactly that kind of email overhead — handling triage, drafting, and follow-ups so those interruptions take less of your day. If the surrounding workflow interests you, the [7-day free trial on Pro or Autopilot](/pricing) covers the full feature set with no commitment.