Why Email Attachments Are Encoded And What It Costs

Email was specified in 1982 to carry text. Not files, not images, text. Everything attached to a message since has been converted into text before sending and converted back on arrival. That conversion adds a third to the size of everything you send.

That cost is invisible until it is not. It decides what fits under an attachment limit, why a folder of saved messages weighs more than the files inside it and why a file that opens perfectly at one end arrives corrupted at the other. Every format in the set of mail formats carries these encoded blocks, because every one of them stores messages that travelled this way.

What the Mail System Was Built to Carry

SMTP was written when a message was a message. Seven bit ASCII, nothing above character 127, short lines. A handful of byte sequences were reserved to mean things like end of message.

A PDF breaks all of that at once.

MIME solved it without changing the transport at all. Rather than teach SMTP about binary, it converts the file into characters SMTP already accepts, then marks the part with a Content-Transfer-Encoding header naming the method so the receiving end can reverse it. RFC 2045, published by the IETF, defines that arrangement and it is still the one in use.

People had solved it badly before that. Uuencode did the same job informally for years without anybody agreeing on the details, which is why very old archives sometimes hold attachments in a form no current client recognises. The value of MIME was less the encoding than the agreement.

Where the Extra Third Comes From

Base64 takes three bytes at a time and writes them out as four characters. That ratio is the whole story.

original    01001101 01100001 01101110
            24 bits, three bytes

regrouped   010011 010110 000101 101110
            24 bits, four groups of six

encoded     T      W      F      u
            four characters, 32 bits

result      3 bytes became 4. Every time.

Four characters where there were three bytes is an increase of a third. Call it 33 percent. That figure is exact rather than approximate. The standard then requires lines no longer than 76 characters, so a line break arrives every 57 bytes of original data and adds a little more.

The working figure is about 137 percent. Cisco puts MIME compliant base64 at roughly that, counting the encoding and the line breaks together. For a rough estimate in your head, add a third and then a bit.

Why a 20MB File Will Not Fit a 25MB Limit

This is where the arithmetic stops being abstract. Attachment limits are stated as a message size. The message is what encoding inflated.

So a twenty five megabyte limit is really a limit of around eighteen megabytes of file. Nobody writes it that way, which is why the rejection feels arbitrary.

Gmail sends 25 and accepts 50. The two numbers are different, which catches people going the other way. A file that arrived in your Gmail perfectly well may be too large for you to forward. Nothing about the message explains why.

The Outlook desktop app has a cap of its own. Connected to an internet account it applies 20 MB regardless of what the web version allows, so the same message can be refused by the app and accepted by the website. Anybody testing in one and sending from the other will get contradictory answers.

Your limit is not the one that decides. A message has to clear every cap on the way. The lowest of them is the one that matters. Your provider may accept something the recipient's rejects. The non-delivery report can then arrive hours after you assumed the thing had landed. Sometimes it does not arrive at all, depending on how the receiving server is configured. Size to the most cautious cap you can guess at rather than to your own.

Why Zipping Sometimes Does Nothing

Compressing before sending is sound advice given without the condition attached to it.

Word documents
spreadsheets
text and CSV
uncompressed images
database exports

JPEG and PNG
MP4 and MOV
MP3
PDF with images
anything already zipped

Why the Body Stays Readable And the Attachment Does Not

Open a raw message and one part is readable while another is a wall of characters. That is two encodings doing different jobs.

A message in French or German uses quoted-printable and stays legible with the accented letters showing as codes. The same message with a photograph attached carries both, one for the body and one for the picture.

Headers use a third arrangement. A subject line in another language cannot use either method directly, so RFC 2047 wraps it in a marker that names the character set and the encoding. A subject that reads as a jumble beginning with an equals sign and a question mark is that mechanism showing through where a client failed to decode it.

Why Modern Servers Did Not End This

Mail servers gained the ability to carry eight bit data directly a long time ago. Binary transmission was standardised after that. Neither displaced encoding, for a reason that has nothing to do with the servers themselves.

The extension only applies where the receiving server announces support for it. That is fine for one hop. A message may cross several, through relays chosen by the recipient's organisation rather than by anybody sending.

One old relay anywhere ruins the whole message. A server that is not eight bit clean does not reject what it cannot handle. It passes it on with the high bits stripped, so the attachment arrives corrupted and nothing reports an error. Encoding cannot fail that way at all, which is the whole reason it stayed.

What This Means When You Are Moving Mail

1. Size attachments to about seventy percent of the stated limit. That is the practical conversion between what a provider says and what a file can weigh.
2. Zip only what compresses. Documents yes, photographs and video no. Above about ten megabytes a link is the better answer anyway, which is what Google Drive, OneDrive and Apple's Mail Drop exist to provide.
3. Expect an archive to outweigh the files. A mailbox export carries everything in its encoded form, so an MBOX archive always weighs more than the same attachments saved to disk.
4. Never treat encoding as protection. Base64 hides nothing. Anything confidential needs real encryption around it, whether that is the transport layer or the file itself.

The third of those catches people mid migration. An EML holds its attachments encoded. An MSG is the exception that proves it, storing them as raw streams because it never had to cross a mail server. So does every container built on messages, which is why a converted archive rarely matches the size anybody predicted. Our EML viewer decodes as it reads, so what you see is the real content rather than the transported form. The converters do the same job when the mail has to move somewhere else.