MIME
Defined by IETF standards
MIME (Multipurpose Internet Mail Extensions) is a standard that extends the original email message format to support attachments, non-ASCII text, and content types beyond plain text, such as images, audio, and structured documents. It…
Definition
MIME (Multipurpose Internet Mail Extensions) is a standard that extends the original email message format to support attachments, non-ASCII text, and content types beyond plain text, such as images, audio, and structured documents. It defines how message bodies are labeled with a content type and encoded so they survive transmission through mail systems designed only for plain ASCII text. MIME's content-type mechanism was later adopted well beyond email, becoming the basis for how web servers describe the kind of data they send.
Overview
MIME was developed in the early 1990s to solve a specific limitation of the original Internet email standard, which assumed message bodies were short lines of plain 7-bit ASCII text and had no defined way to carry binary data, non-English character sets, or multiple pieces of content in one message. As email use grew to include international users and richer content like images and documents, senders needed a way to package that content so it would survive being relayed through mail servers that only understood plain text, without those servers needing to be rewritten. Mechanically, MIME introduces headers that describe a message part's nature: `Content-Type` names the kind of data and its subtype, such as `text/plain`, `image/jpeg`, or `application/pdf`, `Content-Transfer-Encoding` specifies how binary or non-ASCII data was converted into safe ASCII-compatible text, commonly using Base64 encoding or quoted-printable encoding, and `Content-Disposition` indicates whether a part should be shown inline or treated as a downloadable attachment. A single message can be split into multiple parts using a `multipart` content type with a boundary marker, allowing, for example, a plain-text body, an HTML version, and an attached file to travel together in one email. MIME differs from earlier email extensions in that it is fundamentally a labeling and encoding scheme layered on top of the existing plain-text transport, rather than a redesign of the underlying mail protocol itself; this backward compatibility is exactly why it succeeded where a protocol replacement likely would have struggled. Its content-type mechanism proved general enough that HTTP adopted the same `Content-Type` header convention to describe web resource types, meaning the MIME type system now governs far more than just email, spanning web servers, file systems, and APIs that need to label the kind of data they are handling. In practice, MIME types are used every time an email carries an attachment or an HTML-formatted body, every time a web server tells a browser whether a response is HTML, JSON, an image, or a downloadable file, and every time an operating system decides which application should open a file based on its associated type. Developers building web APIs set MIME types like `application/json` or `application/xml` in HTTP headers so clients know how to parse a response, and mail clients rely on MIME parsing to correctly render multipart messages with mixed text and attachments. The main limitation historically associated with MIME is the overhead and complexity of correctly implementing multipart parsing and the various transfer encodings, which has been a recurring source of email client bugs and, at times, of security issues when malformed or misleading MIME headers are used to smuggle disguised attachments. Base64 encoding also inflates binary attachment size by roughly a third compared to sending raw bytes, which matters for bandwidth-constrained transmission. For pure binary data transport where email compatibility is irrelevant, that overhead is unnecessary, which is why later protocols and file formats often choose more efficient binary-native encodings instead of MIME's ASCII-safe scheme.
Specification
- Defines Content-Type headers labeling the kind of message data
- Specifies transfer encodings like Base64 for safe ASCII transmission
- Supports multipart messages combining text, HTML, and attachments
- Provides Content-Disposition to mark inline versus attachment content
- Enables non-ASCII and international character sets in email
- Forms the basis of HTTP's Content-Type header for web resources
- Used by operating systems to associate files with applications
- Backward compatible with plain-text-only mail transport systems