Why your email keeps rejecting a PDF that isn't even that big

Troubleshooting 18 September 2026

The number on the box isn't the number that actually sends

Gmail advertises a 25MB attachment limit. Outlook's free webmail service generally sits around 20MB. Yahoo matches Gmail at 25MB. Those are the published ceilings, and they're real — but a file sitting comfortably under one of them can still bounce, and the reason has nothing to do with the provider being stingy.

Email was built to carry text. It still is, underneath everything. To send a binary file like a PDF or an image through a system designed for text, your email client encodes it using a scheme called Base64, and that encoding inflates the file's size by roughly a third. A 20MB PDF becomes something like 27MB on the wire, comfortably over a 25MB cap it looked well under a moment ago.

It gets worse: you're bound by the smaller of two limits, not just your own

A message has to clear two separate checks: the limit your own provider enforces on sending, and the limit the recipient's server enforces on receiving, and you generally have no way to know the second number in advance. Send a 22MB file from an account with a 25MB cap to someone on an Outlook.com address with a 20MB cap, and it fails on their end, not yours — you may not find out until it bounces back, sometimes hours later.

Corporate email servers make this considerably tighter. Many IT departments configure their Exchange servers well below the provider default, in some cases as low as 10MB, specifically to control mailbox storage and bandwidth. A file that sails through your own personal Gmail can hit a wall the moment it lands on a company's internal mail server.

What actually happens when a file is too big

The behavior differs by provider, which is part of why this is confusing. Gmail and Outlook increasingly intercept an oversized attachment automatically and convert it into a Google Drive or OneDrive link instead of failing outright — convenient, except the recipient now needs the right permissions on that link, and a private or organization-only folder can leave them staring at an access-denied screen instead of a file.

Most other systems simply reject the message and send a bounce notification back to the sender. Occasionally the bounce is delayed, because the sending server accepted the message before the receiving server rejected it — which produces the specific frustration of believing an email was delivered for hours before finding out it wasn't.

A rough table worth keeping in your head

Gmail: 25MB sending, 50MB receiving on personal accounts. Outlook.com: around 20MB, though this varies by whether you're using the website or a desktop client over IMAP. Microsoft 365 business accounts: commonly 25–35MB by default, adjustable by an administrator, though many organizations set it lower rather than higher. Yahoo Mail: 25MB, matching Gmail. iCloud Mail: around 20MB through standard sending, with Apple's Mail Drop separately handling much larger files by uploading them and sending a link that expires after a period of time.

Given the Base64 overhead and the fact that you don't control the recipient's limit, a practical safe ceiling is meaningfully lower than any of these numbers — somewhere around 15–18MB is a reasonable target if you want a file to just work without thinking about it further.

What actually fixes this

For a scanned or photographed PDF specifically, the file is almost always larger than it needs to be, because a phone camera captures far more resolution than a document actually requires to be read. Compressing it before sending is usually the highest-leverage fix, since a ten-page scan at full camera resolution can easily run to twenty megabytes and compress down to a fraction of that without the document becoming harder to read.

For a document that is already reasonably sized and still won't send, splitting it into smaller parts across multiple emails, or using a cloud link deliberately rather than letting the provider force one on you, are the two remaining options — and a deliberate link, sent with correct sharing permissions from the start, avoids the exact access-denied problem that an automatic conversion tends to cause.