What Is Base64 Encoding in Email? Why Attachments Grow

If you have ever sent a 20 MB PDF and had it rejected by a 25 MB server limit you were certain left you headroom, you have met base64 encoding. The file grew in transit. Understanding why — and knowing when a different encoding is used instead — is the whole job of this page.

Email servers were originally built to carry 7-bit ASCII text. Attachments are binary files: sequences of raw bytes that include values outside that range. To get those bytes across legacy mail infrastructure without corruption, MIME re-encodes binary content as printable ASCII text before transmission. Base64 is the encoding MIME uses for that job.

What is base64 encoding in email?#

Base64 encoding is a method of representing binary data — any sequence of bytes — as a string of printable ASCII characters. In email, it is defined by RFC 2045, Section 6.8 as one of the standard Content-Transfer-Encoding values that MIME assigns to message body parts. When a mail client attaches a binary file (a PDF, image, spreadsheet, archive, or any non-text format), it encodes that file in base64 before handing the message to the SMTP server.

The name comes from the 64-character alphabet the encoding uses: the 26 uppercase letters A through Z, the 26 lowercase letters a through z, the digits 0 through 9, plus the characters + and /. Every character in that set falls within 7-bit ASCII, which means it can pass through any mail relay built in any era without being altered or stripped. The equals sign = appears at the end of an encoded block as padding.

At the receiving end, the recipient's mail client reads the Content-Transfer-Encoding header, recognises the value base64, and decodes the stream back to the original bytes before presenting the file. The round-trip is invisible to both sender and recipient. Most users encounter base64 encoding only as an unexpected size problem rather than as a named technical step.

How does base64 encoding work?#

The algorithm operates in fixed-size chunks. It reads 3 bytes — 24 bits — of input at a time and maps them to exactly 4 base64 characters. Each character represents 6 bits: 4 characters times 6 bits equals 24 bits, matching the 3-byte input group. If the total input is not divisible by 3, the encoder pads the final group with one or two = characters to complete the 4-character block.

The ratio is 4 output characters for every 3 input bytes, which means the encoded output is always 33.3% larger than the original. A 15 MB file becomes 20 MB. A 20 MB file becomes roughly 26.7 MB. RFC 2045 also requires the encoder to insert a CRLF line break every 76 characters to keep line lengths within the SMTP specification, adding approximately another 2% on top of the 33% expansion.

The arithmetic is what trips people at attachment limits. A mail server with a 25 MB cap is measuring the complete encoded MIME message, not the raw file. A PDF of 18 MB base64-encodes to roughly 24 MB — safely under. At 19 MB it encodes to roughly 25.4 MB and the server rejects it. The file was within budget on disk; the MIME message was not.

Why does email need base64 encoding at all?#

SMTP, the protocol that moves email between servers, was designed in 1982 for 7-bit ASCII text. It assumes every byte in the message body falls between 0 and 127. Binary files contain bytes with values from 0 to 255, including byte values that SMTP historically used as control characters or line-ending signals. Passing a binary file through a 7-bit transport corrupts it: control bytes get stripped, translated, or misread as protocol commands, and the reconstructed file on the other end is broken.

MIME — Multipurpose Internet Mail Extensions, standardised in RFC 2045 — solved this by introducing the Content-Transfer-Encoding header. The header declares how a body part has been prepared for transport. Setting it to base64 tells every receiving system: decode this stream back to bytes before presenting the content. The encoding is the safety layer that allows binary data to ride 7-bit infrastructure that was never designed to carry it.

Some modern mail servers support the 8BITMIME extension (RFC 6152), which allows 8-bit content to pass without base64 encoding — but only when every server in the delivery chain declares support for it. Because senders cannot verify 8BITMIME availability on every relay, mail clients encode binary attachments in base64 regardless. The extension removes the theoretical requirement; the reality of mixed infrastructure keeps base64 dominant.

Quoted-printable vs base64: which encoding is used when?#

Base64 is not the only Content-Transfer-Encoding defined in RFC 2045. Quoted-printable is the alternative, designed for a different content type. The table below shows the practical distinction.

Common misconceptions about base64 in email#

Base64 is frequently mistaken for compression or encryption. It is neither. The encoded output is always larger than the input — the opposite of what a compressor produces. And base64 is a publicly documented, reversible transformation that anyone can decode without any key or credential. Its only purpose is to represent binary bytes as printable ASCII characters safe for 7-bit channels.

A related mistake: assuming a base64 attachment is confidential because it looks like random noise in the raw message source. The content is fully accessible to any mail relay or server that handles the message, and decoding it takes a single command in any programming language. If confidentiality matters, that requires encryption at the transport layer (TLS) or the message layer (S/MIME, PGP) — not base64.

Finally, people underestimate the size impact mid-workflow. The pattern is consistent: a 20 MB limit sounds fine for a 17 MB video, but after encoding the MIME message is 22.7 MB and it bounces. The practical fixes are to compress the file before attaching it (a ZIP applies its own compression before base64 encodes the archive, so the final encoded size is smaller than encoding the raw file) or to share the file via a link rather than as an attachment, sidestepping the encoding overhead entirely.

How base64 encoding shows up in AI Emaily#

When you attach a file in AI Emaily's composer, the client selects Content-Transfer-Encoding automatically — base64 for binary attachments, quoted-printable for HTML message bodies — and displays the pre-encoding file size alongside the attachment so you can see whether the encoded result will exceed the destination server's limit before the message is queued. The approve-before-send step in Copilot mode shows the attachment name, size, and recipient as a final checkpoint before anything is handed to SMTP, giving you the information to compress or link rather than attach if the size is borderline. We build AI Emaily; the homepage has the full product overview and the pricing page has plan details.

The same logic applies when the AI Emaily agent drafts a reply that includes an attachment in Copilot mode. Approval happens before send, not after — which means a file that would bounce never leaves the draft stage without a human decision. The AI email assistant page covers how the composer and agent interact; the composer tools doc covers the attachment workflow specifically.