How to Use This Tool
Enter the file size as your computer reports it and pick the send limit. The number that matters is the encoded size, because that is what the mail server measures.
Why attachments grow by a third
Email was designed for text, and the protocol still guarantees delivery only for printable characters. Anything else has to be encoded, and the standard method is base64: take three bytes, split their 24 bits into four groups of six, and write each group as one of 64 safe characters.
Three bytes in, four characters out. That is exactly 33.33% larger, every time, with no dependence on the file type — a JPEG, a PDF and a spreadsheet all expand by the same third.
So a 20 MB file arrives at the server as 26.67 MB, and a 25 MB limit rejects it. Working backwards, the largest raw file that fits a 25 MB limit is 18.75 MB.
Compressing first usually does not help
Zipping a file before attaching is the standard reflex and it only works if the file is actually compressible. Documents, spreadsheets and plain text compress well. JPEG, PNG, MP4, MP3 and PDF-with-images are already compressed, and zipping them typically saves under 2% while adding a step for the recipient.
Modern Office formats are the surprising case: .docx and .xlsx are already zip archives internally, so zipping them again achieves essentially nothing.
What does work is reducing the content: exporting a PDF at screen resolution rather than print, resizing images before inserting them, or removing embedded fonts.
Which megabyte
There are two, and they are routinely both called MB:
- MB, decimal — 1,000,000 bytes. What mail providers, storage manufacturers and network speeds mean.
- MiB, binary — 1,048,576 bytes. What most operating systems calculate and then label "MB".
A file your computer calls 25 MB is probably 26.21 decimal MB. Combined with base64 expansion, a file displayed as 19 MB is really 19.92 decimal MB raw and 26.56 MB encoded — over a 25 MB limit, despite looking like it has 6 MB of headroom.
The limit is on the message, not the file
Stated limits cover the whole message: every attachment, the message body, headers, and any embedded images in a signature. Several small files therefore do not each get the full allowance, and the encoding overhead applies to each of them.
Some organisations also apply a smaller receiving limit than their sending limit, so a message can leave successfully and bounce at the other end. If a send succeeds and the recipient never sees it, that asymmetry is the usual explanation.
What to do instead
- A link, not an attachment. Shared storage has no encoding overhead, lets you revoke access, and does not sit in two mailboxes forever.
- Reduce the content. Export a PDF at a lower resolution, downsize images before embedding.
- Split into parts only as a last resort. It works and it is unpleasant for the recipient, and each part still carries the encoding overhead.