MIME format: email structure, content types, and encoding

MIME (Multipurpose Internet Mail Extensions) is a set of standards that extend the basic email format. Before MIME, an email could only carry 7-bit ASCII text: no attachments, no HTML, no non-Latin characters, no images. MIME is defined in RFC 2045–2049 (1996) and has been part of every email message since.

Background: the limits of RFC 822

The original email format (RFC 822, 1982) allowed only US-ASCII characters (codes 0–127) in the message body, with lines capped at 1,000 characters. That worked for English text in academic settings, but by the early 1990s it was clear that files, non-Latin languages, and at least some formatting were needed.

MIME solved this without breaking compatibility. Existing servers kept routing messages by the same rules. The new headers and encodings fit within the 7-bit format, so clients that did not understand MIME simply displayed the raw text.

MIME headers

MIME adds several headers to a message that define the type and structure of its content:

• MIME-Version: 1.0 — a required marker. It tells the receiving side the message uses the MIME standard. The value has not changed since 1996.
• Content-Type — the type of the body (or an individual message part). Format: type/subtype; parameters. For example, text/html; charset=utf-8.
• Content-Transfer-Encoding — how the body is encoded for 7-bit transport: base64, quoted-printable, 7bit, 8bit, or binary.
• Content-Disposition — how the part should be displayed: inline (rendered in the body) or attachment (offered as a download). Can include a filename parameter.
• Content-ID — a unique identifier for a message part, used to reference inline images from HTML via the cid: scheme.

Content-Type: common types

• text/plain — plain text with no formatting. The charset parameter specifies encoding (utf-8, iso-8859-1, windows-1251).
• text/html — HTML content. Every marketing email with layout, buttons, and styles uses this type.
• multipart/alternative — multiple alternative versions of the same content. The typical case: text/plain + text/html. The client picks whichever version it can render.
• multipart/mixed — the message body plus attachments. Each part is a separate object: text, file, image.
• multipart/related — HTML with inline resources. Images are embedded in the message and referenced from HTML via Content-ID (e.g., cid:logo@example).
• application/pdf, image/png, application/octet-stream — specific attachment types. The IANA registry lists more than 1,500 registered types.

Multipart message structure

A multipart message is split into parts using a boundary — a unique separator string declared in the Content-Type header. Each part has its own Content-Type and Content-Transfer-Encoding headers.

The double hyphen at the end (--abc123--) marks the end of the multipart block. The boundary can be any string that does not appear in the body of any part.

Nested multipart structures

A typical marketing email with an attachment has a three-level structure:

• multipart/mixed (top level)
  • multipart/alternative (message body)
    • text/plain
    • text/html
  • application/pdf (attachment)

If the HTML version contains inline images, a multipart/related level is added between alternative and html.

Encoding: base64 and quoted-printable

SMTP was built for 7-bit text. Binary data (files, images) and non-ASCII characters require encoding before they can pass through:

• base64 — represents arbitrary binary data as a 64-character ASCII alphabet (A–Z, a–z, 0–9, +, /). It increases size by about 33%. Used for attachments and images.
• quoted-printable — leaves ASCII characters as-is and replaces non-ASCII bytes with =XX (hex code). The text stays partially readable. A good choice when most characters are ASCII but a few are not.

Modern servers support 8BITMIME (RFC 6152), which lets UTF-8 text pass through without encoding. But for compatibility with older systems, quoted-printable and base64 are still widely used.

MIME and email marketing

A few practical points worth knowing:

• text/plain is required. An HTML-only email with no plain-text alternative is a spam signal. Most ESPs generate a text version automatically, but check that it is not empty and actually contains readable content.
• Size matters. Gmail clips the HTML part when it exceeds 102 KB, showing a "View entire message" link. Heavy inline images inflate the MIME message. Link to images by URL rather than embedding them as base64.
• Use the right charset. If you declare charset=iso-8859-1 but the text contains UTF-8 characters, the recipient sees garbage. Always use charset=utf-8.
• Structure must be valid. A mismatched boundary, a missing closing marker, or incorrectly nested parts can leave the client unable to parse the message. The result is a blank screen instead of an email.

MIME beyond email

The MIME type system extends well beyond email. HTTP uses the Content-Type header with MIME types to declare the format of a response (text/html, application/json, image/webp). Browsers rely on the MIME type to decide how to handle a downloaded file. New types are registered through IANA.