How Email Attachments Work: MIME Encoding, Base64, and Why Binary Files Need Encoding

Email attachments work because binary files are encoded as Base64 — and this has been true since the early 1990s

Before MIME (Multipurpose Internet Mail Extensions, RFC 1341, 1992), email could only transmit ASCII text. Sending a spreadsheet or image required physically mailing a floppy disk or using a separate file transfer protocol. MIME changed this by defining a standard for encoding arbitrary binary data as ASCII text, allowing email to carry any file type. Base64 is the encoding that makes this work.

How MIME works

MIME defines:

1. Content-Type header: tells the email client what type of content follows (text/plain, image/jpeg, application/pdf)
2. Content-Transfer-Encoding header: how the content is encoded (7bit, 8bit, base64, quoted-printable)
3. Multipart structure: allows a single email to contain multiple parts (body text + attachments)

A simple MIME email with an attachment looks like:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==boundary=="
From: sender@example.com
To: recipient@example.com
Subject: Document attached

--==boundary==
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Please find the document attached.

--==boundary==
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="document.pdf"

JVBERi0xLjQKJcfs...
[hundreds of lines of Base64-encoded PDF data]
...

--==boundary==--

The multipart/mixed content type signals that the email has multiple parts. The boundary string separates them. The Base64-encoded PDF begins with JVBERi0xLjQ= (which decodes to %PDF-1.) — the magic bytes of a PDF file, encoded.

Why binary needs encoding for email

Early email systems used Simple Mail Transfer Protocol (SMTP), which was designed to transmit 7-bit ASCII text. Binary files (images, PDFs, executables) contain bytes with values above 127 (8-bit values) and bytes with values 0, 10, and 13 (NUL, line feed, carriage return) that have special meanings in SMTP.

The specific problems:

• Some SMTP servers strip the 8th bit of each byte, corrupting binary data
• SMTP has line length limits; binary data contains random distributions that may violate these
• SMTP uses specific byte sequences as message terminators; binary files may contain these accidentally

Base64 converts binary data to a character set of 64 "safe" ASCII characters (A-Z, a-z, 0-9, +, /) that have no special meaning in SMTP. The receiver decodes the Base64 back to binary.

The 33% overhead and email size implications

Base64 encodes 3 bytes of binary as 4 ASCII characters: 24 bits → 4 × 6-bit groups → 4 ASCII chars

Three binary bytes (24 bits) → four ASCII characters (32 bits, because each ASCII char is 8 bits). Overhead: 4/3 = 33.3%.

Impact on email size:

• A 1 MB image attachment becomes approximately 1.37 MB when Base64-encoded in the MIME message
• A 10 MB PDF becomes approximately 13.7 MB
• Enterprise email storage is significantly inflated by Base64 overhead

This is why some email systems apply compression before encoding (though the standard doesn't require this) and why "compress before sending" advice is useful.

Quoted-Printable: the alternative encoding

Base64 is efficient for binary files. For text that's mostly ASCII but contains some non-ASCII characters (like international characters in email body text), Quoted-Printable is an alternative:

• ASCII characters are transmitted as-is
• Non-ASCII bytes are encoded as =XX where XX is the hexadecimal value
• A French word like "café" becomes caf=E9

Quoted-Printable produces more readable raw email source for text content (you can read an English email even in raw source), while Base64 produces completely unreadable encoded output. MIME allows either for body text; Base64 is standard for attachments.

MIME content types: a partial reference

HTML form file uploads: multipart/form-data

MIME's multipart encoding is also used when uploading files through web forms:

<form method="post" enctype="multipart/form-data" action="/upload">
  <input type="file" name="document">
  <button type="submit">Upload</button>
</form>

The enctype="multipart/form-data" instructs the browser to encode the form submission (including the binary file) as a MIME multipart body in the HTTP request. Server-side code parses this multipart body to access the uploaded file.

Without multipart/form-data, form data is URL-encoded (application/x-www-form-urlencoded) — which can't represent binary file content.

How to use the Base64 Encoder/Decoder on sadiqbd.com

1. Encode text or paste Base64 for inspection or debugging
2. Decode MIME-encoded content: if you've opened raw email source and want to read an attachment, paste the Base64 block and decode it
3. Debug email delivery issues: inspecting raw MIME structure can reveal encoding errors that corrupt attachments
4. Web development: encode small files as data URLs (the inline resource technique covered in a previous article)

Frequently Asked Questions

Why do some emails show as garbled text when forwarded? If an email with a non-US character set (UTF-8 with international characters) passes through a mail server that assumes 7-bit ASCII and strips the 8th bit, accented characters become corrupted. MIME's Content-Transfer-Encoding header specifies how the content is encoded — but some old or misconfigured mail servers don't respect it.

What is a "MIME type" in web development vs email? The same thing — content type identifiers come from MIME and are used in both email (Content-Type header) and HTTP (Content-Type header in HTTP responses). Web servers use MIME types to tell browsers how to handle response content.

Is the Base64 Encoder/Decoder free? Yes — completely free, no sign-up required.

Try the Base64 Encoder/Decoder free at sadiqbd.com — encode any text to Base64, decode any Base64 string, and inspect email attachment content.