RFC 2045: MIME Part 1 — Format of Internet Message Bodies

Standards Track MIME — Multipurpose Internet Mail Extensions Published November 1996

ELI5: Original email could only carry plain English text — like a telegraph. MIME is the invention of the envelope: it lets you put photos, documents, HTML pages, and text in any language inside an email. RFC 2045 defines the envelope itself — the headers that say “this email contains an HTML body encoded in UTF-8” or “there’s a PDF attached, encoded in base64.”

Why This Exists

RFC 5322 (and its predecessor RFC 822) defined email messages as plain US-ASCII text with a maximum line length of 998 characters. That was fine in 1982. It is not fine for modern email, which needs to carry:

Text in non-ASCII character sets (UTF-8, ISO-8859-*, etc.)
HTML content with inline styles and images
File attachments (PDFs, images, archives)
Multiple body parts (text + HTML + attachments in one message)

MIME (Multipurpose Internet Mail Extensions) is a suite of five RFCs that extend email to handle all of this while remaining backward-compatible with the original ASCII-only infrastructure. RFC 2045 is Part 1: it defines the header fields and encoding mechanisms that make everything else possible.

How It Works

RFC 2045 introduces three critical header fields and two encoding schemes.

The MIME-Version Header

Every MIME message must include:

MIME-Version: 1.0

This signals to receiving mail clients that the message uses MIME conventions. Without this header, the message is treated as plain US-ASCII text per RFC 5322. The version has been 1.0 since 1996 and has never changed.

The Content-Type Header

Declares the media type and subtype of the body, plus optional parameters:

Content-Type: type/subtype; parameter=value

Examples:

; Plain text email in UTF-8
Content-Type: text/plain; charset=utf-8

; HTML email
Content-Type: text/html; charset=utf-8

; PDF attachment
Content-Type: application/pdf; name="invoice.pdf"

; Multipart message (text + HTML + attachments)
Content-Type: multipart/mixed; boundary="----=_Part_123"

If no Content-Type is present, the default is text/plain; charset=us-ascii — preserving backward compatibility with pre-MIME messages.

The Content-Transfer-Encoding Header

SMTP was designed to carry 7-bit ASCII text with lines no longer than 998 characters. Binary data (images, PDFs) and 8-bit text (UTF-8) must be encoded to fit these constraints. RFC 2045 defines five transfer encodings:

Encoding	Use Case	Overhead
`7bit`	US-ASCII text (default). No encoding needed.	None
`8bit`	8-bit text (e.g., UTF-8). Requires 8BITMIME SMTP extension.	None
`binary`	Arbitrary binary data. Requires BINARYMIME SMTP extension.	None
`quoted-printable`	Mostly-ASCII text with some non-ASCII characters.	~5-10%
`base64`	Binary data (images, files) or heavily non-ASCII text.	~33%

Quoted-Printable Encoding

Designed for text that is mostly ASCII with occasional non-ASCII characters. Each non-ASCII byte is encoded as =XX where XX is the hex value. Lines longer than 76 characters are soft-wrapped with = at the end.

; Original: "René sent the café menu"
Content-Transfer-Encoding: quoted-printable

Ren=C3=A9 sent the caf=C3=A9 menu

The =C3=A9 is the UTF-8 encoding of é (U+00E9), with each byte hex-encoded.

Base64 Encoding

Encodes arbitrary binary data into ASCII characters (A-Z, a-z, 0-9, +, /). Every 3 bytes of input become 4 ASCII characters. Lines are wrapped at 76 characters.

Content-Type: image/png; name="logo.png"
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34
AAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAAApgAAAKYB
zN+OGwAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBl

Key Technical Details

The Content-Disposition Header

While not part of RFC 2045 itself (it comes from RFC 2183), Content-Disposition is closely related and universally used with MIME:

; Display inline (e.g., an embedded image)
Content-Disposition: inline

; Offer as a downloadable attachment
Content-Disposition: attachment; filename="report.pdf"

A Complete MIME Message

Putting it all together — a message with both text and HTML bodies, plus an attachment:

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

------=_outer
Content-Type: multipart/alternative; boundary="----=_inner"

------=_inner
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Please find your invoice attached.

------=_inner
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<p>Please find your invoice attached.</p>

------=_inner--
------=_outer
Content-Type: application/pdf; name="invoice.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="invoice.pdf"

JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PCAvVHlwZSAv
Q2F0YWxvZyAvUGFnZXMgMiAwIFIgPj4KZW5kb2JqCg==

------=_outer--

Note the structure: multipart/mixed holds the body and attachment. The body itself is multipart/alternative with text and HTML versions. See RFC 2046 for full details on multipart types.

Charset Parameter

The charset parameter on text/* types declares the character encoding. For modern email, always use utf-8:

Content-Type: text/plain; charset=utf-8
Content-Type: text/html; charset=utf-8

Legacy charsets like iso-8859-1, windows-1252, and shift_jis are still encountered but should not be used in new messages.

Common Mistakes

Missing MIME-Version: 1.0. Without this header, some mail clients ignore Content-Type and treat the body as plain ASCII text. Your HTML email will display as raw source code.
Wrong Content-Transfer-Encoding for binary data. Sending a binary attachment with 7bit encoding will corrupt it — null bytes and high-bit characters get mangled. Always use base64 for binary content.
Missing or wrong charset parameter. Omitting charset defaults to us-ascii. If your text contains UTF-8 characters, they'll display as garbage. Always declare charset=utf-8.
Lines exceeding 998 characters. RFC 5322 mandates a 998-character line limit. Base64 wraps at 76 characters. Quoted-printable uses soft line breaks. Raw 8bit text must also respect this limit, or intermediate servers may truncate or reject the message.
Using 8bit without checking server support. The 8bit encoding requires the receiving server to advertise 8BITMIME in its EHLO response. If it doesn't, use quoted-printable or base64 instead.
Boundary string appearing in body content. The multipart boundary must not appear in any body part. Use a long, random boundary string to avoid collisions.

Deliverability Impact

Proper MIME structure is non-negotiable. Malformed MIME triggers spam filters. Missing MIME-Version, incorrect boundaries, or wrong encodings are all red flags that spam filters look for.
Always send multipart/alternative. Include both text/plain and text/html parts. Messages with only HTML are penalized by many spam filters. The text part also serves as fallback for plaintext clients.
Use base64 for attachments, quoted-printable for text. This is the universally compatible combination. It works across every SMTP server and mail client.
Keep attachment sizes reasonable. Base64 encoding adds 33% overhead. A 7.5 MB file becomes a 10 MB email. Many servers reject messages over 25 MB. Some over 10 MB.
Charset correctness prevents rendering bugs. Declaring charset=utf-8 and actually encoding in UTF-8 ensures your email renders correctly worldwide. Mismatched charset declarations cause mojibake (garbled text) and support complaints.