In the beginning, email was created. And email was without formatting, and plain text, and of limited functionality. And MIME said, let there be alternative emails within email, and let the email include both plain text and rich text and whatever formatting folks desire, and it was so.
“My other project is a time machine of course,” wrote Andrew Gray in 2011, forty years after the first networked email was sent, while trying to divine when HTML was added to email in the first place. “First application: preventing HTML e-mail from ever happening,” he said in a message to Jamie Zawinski, better known online as jwz, the developer who built HTML into Netscape Mail in 1995 and in the process shipped one of the first implementations of HTML email.
“Yeah, go back to chipping your USENET posts out with a piece of flint, why don’t you,” retorted Zawinski, before detailing the timeline of when formatted, rich text messages came to other email software, including short-lived text/enriched and text/richtext alternatives. Later versions of Outlook Express “posted HTML by default to both mail and news,” he recalled. “This angered many.”
And, presumably, was widely regarded as a bad move. Only, that bad move is now the default. Most emails you send (as long as you’re not sending mail straight from the terminal with apps like mutt, as Gray was, and as long as you include at least a bit of formatting) are written in rich text and encoded in HTML by default. Tagging alongside should be a plain text copy of the email. Depending on how your message was sent, the email might also include an alternative dark mode inside your message’s CSS, an application/ms-tnef attachment with a rich text copy if (my apologies) you wrote the message in classic Outlook’s rich text mode, an AMP interactive copy if that message originated as a comment on a Google Doc, or (if you went to the trouble of adding it) a simplified HTML version in text/watch-html (for the 1,242 days from Apple Watch’s launch until watchOS 5 added WebKit and, with it, full HTML support).
What looks like a simple email contains multitudes, with alternative versions generated automatically, on your behalf, with little oversight. No wonder it angered many.
How to build an email, in multiparts
Simple emails are still simple. If you open Gmail, and literally type Hello, world! as the subject and body of the email with no formatting—no bold or italics, no links, nothing—your email will be sent in plain text, formatted much like the first emails ever sent:
Simple enough, and not all that much different from what you’d see in your email app aside from Gmail’s added baggage, and the Content-Type: text/plain; charset="UTF-8", which tells your email app that this message is indeed plain text and that everything after the blank line below the headers is the body.
Add a bit more to your email, though, and Gmail will send two versions: A simplified, auto-generated, plain text rendition, along with the formatted message you wrote coded in HTML. Write something like “Hello world, says I, with a link” and Gmail will send something like this:
It’s rather messy, but even if you’re unfamiliar with code you can see what’s going on. It starts with the now-familiar From, Date, Subject, and To lines, along with Gmail’s extra bits. And then something new: Content-Type: multipart/alternative;, signifying that this email contains multitudes, with boundaries to tell your email app where each part starts and ends.
First comes the text/plain version, similar to the first email, with the addition of Markdown-style asterisks for the italicized text (fittingly enough, since Markdown itself was inspired by plain text email markup), and a link offset in angle brackets. It’s faithful to what you wrote, yet, uncannily, is something the email app is sending on your behalf without you ever seeing how it looks.
Then comes the text/html version, with your formatted text rendered in HTML and wrapped in a div, details you’ll seldom see as your email app will render it as rich text and, unless you dig into the email source, you’ll never see how the formatting was made. It renders faithfully to how you formatted your message in Gmail, at least in most email apps, and that’s what matters: Recipients see what you created and sent.
Two versions, in one email trench coat.
Now, send that email as a newsletter, say with Buttondown, and it’s still two versions in one email. Only, this email will include quite a lot more detail in the header, and a longer HTML section complete with CSS design—which could include @media queries for a dark mode email theme and a mobile-friendly layout. Three or four versions, in one email trench coat, if you squint.
Buttondown stays faithful to the exact text you wrote. Your newsletter’s plain text version will be formatted in Markdown, exactly as it looks if you use Buttondown’s Markdown Mode (which, incidentally, is the best way to preview the plain text copy before hitting send). It does also include a plain text footer that you can customize separately from your theme’s default HTML footer, one spot where you may want to watch for divergence.
That’s the ideal situation, but not always how things work. Say you customize your template with hard-coded text; that won’t show up in the plain text preview. Or, if your template includes sample text like the “Use this area to offer a short preview of your email's content”-type bits that I’ve seen slip through in real emails plenty of times, you’ll be writing one email and sending something somewhat different.
And then there are the edge cases. Schedule an event in Outlook or Google Calendar, and your email will include a Content-Type: text/calendar section with meeting details that your email app may render complete with Accept and Decline buttons (for a fourth message bit hiding under your email’s coattail). Add a comment in a Google Doc, and the notification email will include a Content-Type: text/x-amp-html section that, in Gmail at least, can show comments added after the email was sent and let you reply without leaving Gmail’s interface. And as unlikely as it is that you’ll see a real one in the wild today, there are the aforementioned text/enriched and text/richtext and text/watch-html bits that, through the years, have tagged alongside the plain text and other versions of the message folks thought they were sending.
An attempt to make everyone happy
It would have been easier to keep email plain text only, as subject lines remain to this day. Easier, but not better. We wouldn’t have gotten multilingual emails beyond what English-centric ASCII could handle, though, that or attachments.
That’s why Nathaniel Borenstein and Ned Freed expanded email with MIME. The whole goal was being able to email photos in a project that along the way expanded to “provide facilities to include multiple objects in a single message” with images and alternative character sets and internationalization alongside, and “generally to facilitate later extensions defining new types of Internet mail for use by cooperating mail agents.” And here be dragons, the ones that made Gray want a time machine to vanquish them. Email could contain pretty much anything, as long as you broke it down into a new multipart section.
“We avoided trying to settle as many battles as we could,” Borenstein would later write, “preferring instead to create a framework for the debate to continue.” It didn’t dictate that all email messages should be in ASCII, instead giving a way to mark that your email was formatted in another format, and eventually we’d land on the universal UTF-8 (a standard published a year after MIME). It didn’t say images had to be JPEG or GIF, it just gave an image/ tag that could be extended with any image format.
Which is how email has ended up with multiple rich text formats over the years. By the time MIME came out, in 1992, the then-fledgling world wide web was less than a year old, and it was only a matter of time before people would wonder why their email messages didn’t look as nice as a web page. What if email let you include links and dancing baby GIFs, folks wondered. And an HTML version of the email in a new MIME section made it so, while the less-used rich text variants faded away.
New MIME sections didn’t replace the old, either. MIME dictated that messages “should put the plainest format first and the richest format last,” while email apps themselves “should pick and display the last format they are capable of displaying.” Every email should include plain text, the original baseline, most accessible by older software and by accessibility tools like screen readers. Uncommon variants, such as Google AMP, are slipped in next, usable only by apps like Gmail that can read them. Then, typically last, comes HTML, the rich format most modern email apps should display.
Pulling back the curtain
It’s a mess, in a way, but one that most of the time stays quietly hidden beneath your inbox. You read the rich, formatted version of emails, formatted for your display and viewing mode, and would only ever see an alternative take if you’ve set your email app to display plain text or are using a plain-text email app, such as the terminal email app Mutt.
That, or when some apps use the plain text version as the preview text before you click on a message. Or when an automation like a Zapier workflow uses the plain text version to process your email which can break workflows when a message includes only HTML or has an incomplete plain text alternative. Or when your email app’s AI agent, as is increasingly common, reads your email, where it could read the plain text or HTML versions (and where they could be susceptible to prompt injections from otherwise-hidden text in the plain text or a non-rendered div in the HTML). Or, worse, when spam filters process your email, where they’re likely to check the entire text of your message—plain text and HTML alike—and compare the versions against each other. If your plain text version shares almost no words from the HTML version (or, conversely, contains multiple times more text than the HTML), SpamAssassin for one will count against your email and be more likely to rank it as spam.
Most of the time, you the email sender have nothing to worry about. Your email app and newsletter sending service will automatically generate the correct versions of your email, while readers will see exactly what you intended. And yet. It is somewhat disconcerting to know that an email agent in the background is cooking up a different version of your email on its own, just enough that it’s worth checking every now and then.
Send yourself a test email. Click Show Original in Gmail, Message > Raw Source in Apple Mail, View > View message source in Outlook, or View > Message source in Thunderbird. And read through the code. Search for Content-Type to jump to the message bodies, and see what you find. You might find some divergence that you’d like to tweak in your theme or email sending settings. You might find that your app translates formatting in unexpected ways. You might, even, find out that something’s missing, that your app isn’t sending a plain text copy at all, or is sending filler text instead of your message.
You might be surprised by what you find. I, after inspecting dozens of emails while writing this piece, found that a Welcome to Apple Developer Program email I received mid-2026 includes only an HTML version—no plain text included—and has alt text that mentions the iPhone XS, a phone originally shipped eight years earlier and that received its final updates months earlier. It was an email that hadn’t been updated in years, and is perhaps the best example of why it’s worth reading every bit of your multipart emails every once in a while.
The email formatting we inherited is a kludge of sorts, with endless alternative takes tacked on one after another. It works, it just requires a bit of vigilance to ensure you’re sending what you intended, so you don’t end up wishing you had a time machine to go back and undo send.
| Image | Credit |
|---|---|
| Header photo | Jorge Campos via Unsplash |