The attachment limit is not the number you were told

Mail systems advertise one size and enforce a smaller one, because of an encoding step nobody mentions. Here is where the missing quarter of your budget goes, and what to do about a photo folder that will not send.

Everyone knows the number for their own provider. Gmail says 25 MB. Outlook.com says 20 MB. A corporate Exchange server says whatever an administrator typed into a policy years ago, often 10 MB. What almost nobody is told is that those figures describe the message after encoding, and encoding makes your files bigger before they leave the building.

Email cannot carry a file

SMTP was designed for text. A JPEG is not text, so before it can travel it is re-expressed in a printable alphabet, normally base64, which represents every three bytes of your file using four characters. That is a fixed overhead of about a third, plus line breaks. A 20 MB folder of photos becomes roughly 27 MB of message body. Against a 25 MB ceiling it bounces, and the error rarely explains why.

The receiving end has its own opinion

The limit that matters is the smaller of the sender's and the recipient's, and you cannot see theirs. A message that leaves your outbox happily can be rejected several hops later by a mail server with a stricter policy, sometimes hours afterwards. This is the mechanism behind the familiar experience of a large attachment that appears to send and then fails in the middle of the night.

A second, quieter rule catches people out: many gateways strip or quarantine certain file types regardless of size. Anything executable, and often anything zipped, may be removed silently. A PDF or an image almost always survives.

What to do about a folder of photos

There are only three real moves, and they are worth understanding as a hierarchy rather than a list.

• Change the format first. This is the largest, cheapest saving and it costs almost no visible quality. Phone photos arriving as HEIC are already efficient, but the moment you convert them to PNG to make them openable they can grow several times over, which is exactly what happens when someone converts a camera roll for a relative on Windows and then tries to email the result. Convert HEIC to JPG for people and JPG to WebP for web pages, and the problem usually disappears on its own.
• Then reduce the dimensions. A modern phone photo is around twelve megapixels. Nobody reading it in an email client sees more than about two. Halving the width and height quarters the pixel count, and that is a far bigger saving than any quality slider, with a far smaller visible cost.
• Compress last. Re-encoding at a lower quality target is the tool people reach for first and it should be third. It works, and compressing a JPG is a legitimate final squeeze, but it is the only one of the three that visibly degrades the image, and on an already-compressed file it degrades it twice.

When to stop fighting it

Past a couple of dozen photos, email is the wrong pipe. Both Gmail and Outlook will offer to replace a large attachment with a link to cloud storage, and that is not a downgrade: the recipient gets the originals at full quality, and neither mail system has to carry 30 MB of base64. Reserve attachments for the handful of files that need to sit in the thread as a record.

One habit is worth keeping either way. Send yourself a copy first, on a different device if you can, and open it. Two minutes of checking has saved more documents than any size calculation.

Sources and caveats

• The base64 overhead is arithmetic rather than a measurement: four output characters per three input bytes, defined in RFC 2045, plus a line break every 76 characters.
• Provider ceilings are the published figures at the time of writing: Gmail and Outlook. Check your own provider's current documentation, and your administrator's policy if you are on a corporate account, because neither is something this site can measure for you.