What Is MIME in Email? Multipart Messages Explained
The short answer
MIME (Multipurpose Internet Mail Extensions) is the standard, defined in RFC 2045-2049, that lets plain-text email transport carry HTML, attachments, and non-ASCII characters. It adds headers like MIME-Version, Content-Type, and Content-Transfer-Encoding that tell your mail client what each part of a message is and how to decode it.
What is MIME in email? The RFC standard that lets plain-text mail carry HTML, attachments, and non-ASCII text — and how its headers work.
On this page
Open almost any email today and you are looking at MIME at work: a formatted HTML layout, an inline logo, a PDF attachment, maybe an emoji in the subject line. So what is MIME in email? MIME is the standard that lets a mail system built only for plain text carry all of that at once.
The name stands for Multipurpose Internet Mail Extensions. It was defined across RFC 2045 through RFC 2049, first published in 1996, and it is still the foundation every modern message rides on. This guide covers what MIME does, the headers it adds, and how it structures the body of a message.
What does MIME stand for, and what does it do?#
MIME stands for Multipurpose Internet Mail Extensions. The original email standards assumed a narrow world: SMTP moved messages as 7-bit US-ASCII text, and RFC 822 described a message as a header block followed by a plain-text body.
That was fine for typed English. It could not carry a photo, a spreadsheet, a Japanese sentence, or bold text — the bytes those need do not fit in 7-bit ASCII. MIME extends the format so one message can hold all of them, without breaking older software that only understands plain text.
- Rich formatting — HTML email with headings, links, and styling
- Attachments — images, PDFs, spreadsheets, and any other file type
- Non-ASCII text — accented, Cyrillic, Arabic, or CJK characters, and emoji
- Multiple versions of one message — a plain-text and an HTML copy side by side
The MIME header fields#
MIME works by adding header fields that describe the content. Four fields do most of the work. The first three are defined in RFC 2045; Content-Disposition comes from a separate standard, RFC 2183.
| Header | What it declares | Example value |
|---|---|---|
| MIME-Version | That the message follows the MIME standard | 1.0 |
| Content-Type | The media type, plus the charset for text or the boundary for multipart | text/html; charset=utf-8 |
| Content-Transfer-Encoding | How the part's bytes were packed so 7-bit transport can carry them | base64 |
| Content-Disposition | Whether a part shows inline or downloads as an attachment (RFC 2183) | attachment; filename=report.pdf |
MIME-Version has always been 1.0
How does MIME encoding work?#
Because the transport historically only guaranteed 7-bit text, binary data has to be re-expressed using printable ASCII. That translation is the job of the Content-Transfer-Encoding header, which names how the part's bytes were packed.
RFC 2045 defines five values. Two matter most day to day: quoted-printable for mostly-text content, and base64 for files.
| Encoding | Used for | What it does |
|---|---|---|
| 7bit | Plain US-ASCII text | No change — the default when the header is absent |
| quoted-printable | Text with a few non-ASCII characters | Encodes only the odd byte as =XX and leaves the rest readable |
| base64 | Images, PDFs, any binary file | Re-encodes bytes using a 64-character alphabet; about 33% larger |
| 8bit / binary | Raw high-bit or unencoded bytes | Passes bytes through, so it needs a transport that supports them |
base64 is encoding, not encryption
How does MIME build a multipart message?#
A single message often needs to hold more than one thing at once — an HTML body with its plain-text fallback, or a written message plus two attachments. MIME does this with the multipart content type, defined in RFC 2046.
The body is split into parts by a boundary string named in the Content-Type header. Each part begins with two hyphens followed by that boundary; the message ends with the boundary wrapped in two hyphens front and back. Every part carries its own Content-Type and its own encoding.
The two subtypes you meet most are multipart/mixed and multipart/alternative. Mixed keeps distinct parts together, which is how a message carries attachments. Alternative holds the same content in two formats and lets the client pick — RFC 2046 orders the parts from least to most faithful, so the client shows the last version it can render.
Why does MIME matter?#
Without MIME, email would still be a plain-text teletype. Every attachment, every formatted newsletter, every message written in a non-Latin script depends on it.
You notice MIME mostly when it goes wrong. If a client cannot read the Content-Transfer-Encoding, you see raw base64 or stray =20 sequences instead of text. If the Content-Type is wrong, a PDF might open as gibberish, or an HTML body might display as raw source code.
- Attachments arrive as unreadable text or fail to open
- HTML shows as raw tags instead of a formatted layout
- Accented or non-Latin characters turn into mojibake (garbled symbols)
- The wrong part displays — plain text where HTML was meant, or the reverse
MIME vs the email header: what is the difference?#
MIME is easy to confuse with the email header, because MIME's fields sit in the header area too. The difference is what each one describes. The email header is the message's metadata — who sent it, to whom, and when. MIME describes the content — what the body contains and how to decode it.
| Email header (RFC 5322) | MIME (RFC 2045+) | |
|---|---|---|
| The question it answers | Who, to whom, when, what subject | What each part is and how to decode it |
| Typical fields | From, To, Date, Subject, Message-ID | MIME-Version, Content-Type, Content-Transfer-Encoding |
| Governing standard | RFC 5322 (formerly RFC 822) | RFC 2045-2049; Content-Disposition in RFC 2183 |
| Scope | Message metadata and routing | Body structure and content encoding |
| Remove it and… | No addressing, subject, or threading | Only plain US-ASCII text — no HTML, files, or accents |
How AI Emaily reads MIME messages#
Every email app has to parse MIME before it can show you a message: it walks the Content-Type tree, chooses which alternative part to display, decodes the base64 or quoted-printable body, and lists attachments from their Content-Disposition headers. AI Emaily is an AI email client, so it does exactly this — the standard is the standard for everyone.
Where it differs is what happens after decoding. It treats the rendered HTML as untrusted input: tracking pixels are blocked and links are sandboxed before a part reaches the screen. When its agent drafts a reply, it produces a proper multipart message — a plain-text alternative alongside the HTML — rather than shipping raw text a strict reader would mangle. We build AI Emaily, and how it handles the raw message is part of what it is.
Frequently asked
See it in AI Emaily
Keep reading
Sources
Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.