MIME
MIME is the set of rules that lets an email carry more than plain ASCII text: HTML, attachments, images, and characters outside the original alphabet. It defines the headers that declare a part's type and encoding, and the multipart structure that nests parts inside one another. Every modern message is a MIME document, whether or not anybody writing it ever thinks so.
At a glance
- Category
- Message format
- Full name
- Multipurpose Internet Mail Extensions
- Declares
- Content-Type, Content-Transfer-Encoding, charset, boundaries
- Alternative parts
- Plain text and HTML, in increasing order of richness
- Attachments
- Parts with a Content-Disposition of attachment
- Specified in
- RFC 2045 and RFC 2046
How it works
A message declares a content type. When it needs to carry several things at once it uses a multipart type and a boundary string that separates the parts. A message with both a plain text and an HTML version uses multipart/alternative, listing them from simplest to richest so a client can pick the best one it supports. A message with attachments wraps that structure in multipart/mixed. Each part carries its own type, character set and transfer encoding, and parts can nest.
Why it matters
Nearly every rendering problem in email is a MIME problem underneath. A message that shows raw HTML has a wrong content type, a message whose accents turn into symbols has a wrong character set, and an attachment that arrives as gibberish has the wrong transfer encoding. Knowing the structure also tells you what a receiving system sees: an inbound webhook's text and HTML fields are the alternative parts, and its attachment list is the mixed wrapper.
Example
A notification is built as multipart/alternative with a plain text part and an HTML part, both declared as UTF-8 so an accented name renders correctly everywhere. A customer replies and attaches a screenshot, so their client wraps the alternative pair inside multipart/mixed and adds an image part marked as an attachment. The receiving endpoint parses all of it and hands the application both bodies plus a reference to the image.
Common mistakes
- 01Sending HTML with no plain text alternative, which reads badly in clients that prefer text and looks careless to some filters.
- 02Declaring the wrong character set, which is why accented characters and emoji turn into replacement symbols.
- 03Building multipart bodies by string concatenation, where one wrong boundary makes the whole message unreadable.
- 04Inlining large images as parts rather than linking them, which inflates every copy of the message by a third and trips size limits.
Related terms
Frequently asked questions
Do I need to send a plain text part?
It is strongly advisable. Some clients and some readers prefer text, and a message with only an HTML part is a small negative signal to certain filters.
Why do my accented characters break?
The character set declared on the part does not match the bytes actually sent. Declaring UTF-8 and encoding the body as UTF-8 resolves almost every instance of this.
Is there a size limit on attachments?
Not in MIME itself, but every receiving server enforces one, and transfer encoding inflates the payload by roughly a third. Sending a link to a file is more reliable than sending a large attachment.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.