A soapbox moment about HTML (rich text) formatted e-mail

Print Friendly, PDF & Email

Someone is probably gonna try to rip me for having published this blog entry. Before you do, let me affirm solidly that this is an opinion and I’m not setting out on a crusade. I’m allowed my opinion.

The opinion to which I refer is: I loathe the fact that formatting e-mail in HTML (a.k.a. Rich Text) instead of plain text is far more prevalent than it should be. And I don’t even fault the majority of us who do the e-mailing. I fault e-mail application developers who now make HTML/Rich Text formatting the default.


The most common purpose of an e-mail is to send a few thoughts in written form to another person. Period. Plain text is all anyone needs for just about all their e-mailing needs.

There are many reasons to stick with plain text. For one, it’s more compatible across all e-mail systems. HTML/Rich Text is an interpreted and rendered format. It’s not as simple as just typing a few characters. Some sort of tag is used to apply some sort of styling to all the text, and it’s in those tags that problems can occur if one e-mail application represents a particular tag differently than another e-mail application. The result: what the sender sees is not necessarily what the recipient will get.

Second reason: bad ju-ju can live in those formatting codes. Never mind that virus scripts can work their way into that code—do you know how spammers usually know that you’ve opened (even if you didn’t read, but at least opened) their e-mail? They include a link to a graphic—maybe even just an invisible single-pixel graphic. The URL path to that graphic is coded so that every spam e-mail has a unique number. If the e-mail is opened, usually the e-mail application will call out to the internet to pull in that graphic so it displays in the e-mail message. Because the URL to that graphic is unique in every message, the spammers then know that the e-mail address associated with that URL number is a valid address because their server registers that the graphic was requested.

This is why I always use the option in e-mail applications to never automatically download images from remote servers. Entourage (and many other applications) includes a link that I can use to download the images later if I determine the e-mail is from a trusted source. But even for trusted sources, the e-mail message will look bad, with broken image link icons, when I first open it.

Third reason: size. I just sent three sample e-mails to myself, all with the exact same text. There was a header line, then there was several lines of repeating asdf asdf asdf asdf…

In the text-only e-mail, this message weighed in at 1.6 kilobytes. Switching to HTML formatting, the exact same text without a single change to formatting went up to 2.65 kilobytes. In the third sample e-mail, I still left the actual text alone, but I italicized one of the several lines of repeating “asdf” characters, and on the header line of text where I typed that it was a test e-mail, I boldfaced it, enlarged the size, and changed the typeface. Other than these style changes, I did nothing to the actual text. The third sample e-mail went up a little more, to 2.76 kilobytes.

Okay, yes. This is tiny. Why am I complaining about 2-3 kilobytes as opposed to 1.6? Because this is a very lightweight example. The content was very short and was was only comprised of text content. E-mails of more typical length will grow considerably larger. And, don’t forget all those silly e-mail themes that e-mail clients provide which throw backgrounds, colored graphical headers, etc. throughout the message. There’s also the many people who think it’s nice to have a graphic scan of their handwritten signature in the e-mail.

As a result, the e-mail file size begins to grow seemingly exponentially. It suddenly takes a few dozen kilobytes instead of just a 3-4 kilobytes to let me know that a meeting has been rescheduled for a half hour later in the day. Multiply this by the dozens and dozens of e-mails I process every day, and—well, let me just say that I have a cap on the maximum amount I can store in my work e-mail account, and I constantly have to purge the big stuff out of the Sent and Deleted Items folders.

People have been all abuzz about the Twitter notification e-mails that inform users of new followers. Twitter, for the love of Pete, please give an option to go back to text-only e-mails. The old text-only notifications were about 2 or 2.5 kilobytes. The new HTML-formatted e-mails that not only contain links to remote graphics (which show as broken image link icons since I don’t auto-retrieve them) but also has several graphics embedded in the e-mail are now 7-8 kilobytes.

Once again, I realize this is still tiny amounts, relatively speaking, and I’m going to get people telling me, “So what? Can it, will ya?” Fine. But if the size rationale means nothing to you, my first two rationales should do a bit better. Yes, there are some times where an HTML-formatted message is useful—and I have been known to use them in certain cases. Most commonly, I’ll use HTML formatting when editing an article that someone sent to me via e-mail. Text that I ask to have removed, I’ll change to red color, but leave it in place so the other person sees what text I asked to remove. Text that I want added, I’ll type in green. But, the times when HTML formatting is useful is generally the exception—not the rule.

My hope is that you’ll realize plain text is most adequate for the majority of your e-mail and that you’ll change your e-mail application to default using plain text, manually switching to HTML formatting on an individual message basis, as needed.

2 Responses

  1. Chris says:

    It’s worse than you show in your example:


    Mail.app is particularly bad; I haven’t done a comparison with other clients to see if they’re better or worse, but I’ve seen similar output from whatever M$ is calling their mail client on Windows these days, too.


  2. Lee Bennett says:

    Thanks for helping me make my point, Chris.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.