1991: MIME: When Email Learned to Send More Than Text

Try to imagine email without attachments. No PDFs attached to invoices. No photos shared with family. No HTML formatting, no embedded images, no file transfers. Just plain text — and not even good plain text, since the original email specification only supported 7-bit ASCII characters, which meant no accented letters, no Asian characters, and definitely no emoji.

That was email for its first twenty years. Then, in June 1991, two engineers published a specification that cracked the box wide open.

The 7-Bit Prison

When Jon Postel defined email’s message format in RFC 822 (1982), he specified that email bodies should contain only 7-bit ASCII text. This was a practical decision — the underlying SMTP protocol was designed to transport text, and many systems in the early 1980s couldn’t reliably handle 8-bit data. ASCII gave you 128 characters: the English alphabet (upper and lowercase), numbers, basic punctuation, and some control characters.

For ARPANET researchers sending technical notes to each other in English, this was fine. But as email spread beyond American universities and government labs, the limitations became painful. French users couldn’t type accented characters. Japanese users couldn’t use their own writing system. Nobody could attach a file to a message.

People developed workarounds. The most popular was uuencode, a Unix utility from 1980 that could convert binary files into ASCII text. You’d uuencode a file, paste the garbled-looking result into an email, and the recipient would uudecode it on their end. It worked, technically, but it was clunky, error-prone, and utterly hostile to non-technical users.

Borenstein and Freed’s Solution

Nathaniel Borenstein, a researcher at Bellcore (Bell Communications Research), and Ned Freed, at Innosoft International, saw the problem clearly. Email needed a standardized way to carry arbitrary content — not just text, but any type of data — while remaining compatible with existing 7-bit SMTP infrastructure.

Their solution, published in June 1991 as RFC 1341, was MIME: Multipurpose Internet Mail Extensions. The design was elegant. MIME didn’t change SMTP or the basic email format. Instead, it added new headers that described what kind of content an email contained and how that content was encoded.

The key innovations were straightforward but transformative. Content-Type headers told the receiving system what kind of data was in the message — text, image, audio, video, application data, or multiple types combined. Content-Transfer-Encoding specified how binary data was converted to survive the 7-bit ASCII transport layer, with Base64 becoming the standard encoding method. Multipart messages allowed a single email to contain multiple pieces of content — a text body plus an HTML version plus three file attachments, all bundled together.

The Multipart Revolution

Perhaps MIME’s most impactful feature was the multipart message type. A multipart message could contain any number of body parts, each with its own Content-Type and encoding. This enabled several things that we now take completely for granted.

First, it enabled attachments. A file could be Base64-encoded, wrapped in its own MIME body part, and bundled into the email. The receiving email client would recognize the attachment, decode it, and present it to the user as a downloadable file. Second, it enabled alternative representations. The “multipart/alternative” type allowed senders to include both a plain text version and an HTML version of the same email, letting the recipient’s client display whichever one it supported. This is still how every marketing email works today.

Third, it enabled inline images and rich content. The “multipart/related” type allowed HTML emails to reference embedded images, making truly rich email layouts possible.

The HTML Email Consequence

MIME didn’t just enable attachments — it enabled HTML email, which would transform email marketing from a text-based medium into a visual one. Once email clients could render HTML, marketers could send branded, designed messages with logos, colors, buttons, and layouts.

This was a mixed blessing. HTML email made marketing more engaging and effective, but it also introduced a wave of security concerns (malicious scripts, tracking pixels, phishing attacks that looked like legitimate bank emails) and created an entirely new discipline of email design that still frustrates developers today. Coding HTML for email remains notoriously painful because different email clients render HTML differently — a problem that wouldn’t exist if we’d all stayed in plain text land.

Why It Matters

MIME is one of those technologies that became so successful it became invisible. Nobody thinks about MIME when they attach a spreadsheet to an email or receive an HTML newsletter. But MIME is doing the heavy lifting in every single one of those interactions.

The standard has been updated several times — RFC 2045 through RFC 2049 (1996) replaced the original specification — but the core architecture remains the same. Every email client in the world, from Apple Mail to Gmail to Thunderbird, implements MIME to handle attachments, HTML content, and non-ASCII text.

Borenstein reportedly celebrated MIME’s publication by sending one of the first MIME emails to the Internet Engineering Task Force (IETF) mailing list. The email included an audio attachment of him singing “Let Me Send You Email” to the tune of “Let Me Call You Sweetheart.” It was exactly the kind of thing you couldn’t do before MIME.

Today, when you’re crafting HTML emails for marketing campaigns, you’re building on MIME’s foundation. Make sure your content doesn’t trigger spam filters by checking it with our Spam Word Checker before you hit send.

Infographic

Share this visual summary. Right-click to save.

Frequently Asked Questions

What does MIME stand for in email?

MIME stands for Multipurpose Internet Mail Extensions. It was introduced in 1991 by Nathaniel Borenstein and Ned Freed to allow email to carry non-text content like images, audio, video, and file attachments.

What could email do before MIME?

Before MIME, email could only carry plain ASCII text — 7-bit characters with no formatting. You couldn't attach files, embed images, send formatted HTML, or even use characters from non-English alphabets.

Is MIME still used in modern email?

Absolutely. Every email with an attachment, HTML formatting, or embedded image uses MIME encoding. When you attach a PDF to a Gmail message, MIME is the system that packages it for transmission.