HTML emails use a specific part of HTML to add formatting and structure that plain text emails can’t offer. With HTML emails, you can:
- Add links without showing the full URL.
- Avoid breaking long URLs into multiple lines.
- Adjust text to fit the width of the viewing window instead of sticking to a fixed width (as required by RFC 5322 for old text terminals).
- Include images, tables, diagrams and mathematical formulas directly in the email, making it easier to share complex information that plain text can’t handle well.
This makes HTML emails more versatile and visually appealing compared to plain text emails.
Adoption
Most email programs support HTML emails and often set them as the default. These programs usually offer both a visual editor for writing HTML emails and a tool for displaying them.
Since HTML emails started, some people have strongly opposed them. For example, the ASCII Ribbon Campaign wanted all emails to be in plain text format. This campaign ended in 2013. Although HTML emails are still not preferred in some newsgroups and mailing lists, their use in personal and business emails has grown. Many people who initially opposed HTML emails now see them as mostly harmless.
Surveys by online marketing companies show that almost everyone now uses email clients that support HTML, with less than 3% sticking to text-only clients. Most people prefer receiving HTML emails over plain text ones.
Compatibility
Email programs that follow RFC 2822 standards are only required to support plain text, not HTML formatting. This means that if you send an HTML email and the recipient’s email program doesn’t support it they might see the raw HTML code instead of the message.
Even among email programs that do support HTML, some don’t display it according to W3C standards. Additionally, many HTML emails are not properly coded, which can cause display or delivery issues.
The <head> tag which is used for CSS style rules in HTML documents, isn’t well supported in many email clients. Sometimes, it’s removed entirely, making in-line styles the default. In-line styles are less efficient and don’t fully utilize HTML’s ability to separate style from content.
This issue has frustrated many newsletter developers, leading to the creation of the grassroots Email Standards Project. This project grades email clients on their ability to properly render HTML and advocates for better support. For example, to encourage Google to improve Gmail’s rendering, they published a video of web developers expressing their frustration which caught the attention of a Google employee.
Email Standards Project Acid Test Comparison (as of January 2013) Archived on December 6, 2017, at the Wayback Machine
| Email Client | Result | Date |
| AOL Webmail | Solid support | 13 July 2011 |
| Apple iPhone | Solid support | 13 July 2011 |
| Apple iPad | Solid support | 13 July 2011 |
| Apple iPod Touch | Solid support | 13 July 2011 |
| Apple Mail | Solid support | 28 November 2007 |
| Apple MobileMe | Solid support | 15 August 2008 |
| Eudora | Solid support | 28 November 2007 |
| Eudora OSE (“Penelope”) | Solid support | 28 November 2007 |
| Microsoft Entourage | Solid support | 28 November 2007 |
| Mozilla Thunderbird | Solid support | 28 November 2007 |
| Windows Live Mail | Solid support | 28 November 2007 |
| Windows Mail | Solid support | 28 November 2007 |
| Yahoo! Mail Beta | Solid support | 8 July 2011 |
| Windows Live Hotmail | Some improvement recommended | 8 July 2011 |
| Google Gmail | Improvement recommended | 13 July 2011 |
| Lotus Notes 8 | Improvement recommended | 28 November 2007 |
| Microsoft Outlook 2007 | Improvement recommended | 28 November 2007 |
Style
Some email senders use large, colorful or distracting fonts which can make their messages harder to read. For those annoyed by such formatting, some email programs allow users to override it partially. For example, Mozilla Thunderbird lets you set a minimum font size. However, not all email programs offer this feature.
Additionally, the difference in how emails appear to the sender and the reader can help distinguish who wrote each section, improving readability.
Multi-Part Formats
Many email servers automatically create a plain text version of a message and send it along with the HTML version. This ensures the email can be read by both text-only and HTML-capable email clients. This is done using the Content-Type: multipart/alternative as specified in RFC 1521.
The email itself is of type multipart/alternative and has two parts:
- text/plain: Read by text-only clients.
- text/html: Read by HTML-capable clients.
However, the plain text version might miss important formatting details. For example, a mathematical equation could lose a superscript, changing its meaning entirely.
Many mailing lists intentionally block HTML emails. They either remove the HTML part, leaving only the plain text or reject the entire message.
The order of the parts in a multi-part email is important. According to RFC 1341, email clients should list the body parts in increasing order of preference, with the most preferred format last. This means that in emails with both HTML and plain-text versions, the plain-text version should be listed first, followed by the HTML version. If this order is not followed, the email client might show the plain-text version even if an HTML version is available.
Message Size
HTML emails are larger than plain text emails. Even without special formatting, the HTML tags add extra size. When heavy formatting is used, the size increases more. Multi-part messages which include both plain text and HTML versions are even bigger. However, with IMAP’s FETCH command you can retrieve just the plain text part of a multi-part message.
In the 1990s, when people used slow modems, the larger size of HTML emails was a concern because it took longer to download. Nowadays, with faster internet connections, this difference is negligible for most people, especially compared to the size of images, music files or other attachments.
Security Vulnerabilities
HTML emails can display links as any text, hiding the actual URL. This can be used in phishing attacks, where users are tricked into thinking a link leads to a trusted site (like a bank) but it actually takes them to a scam site, where they might reveal personal information.
Emails can also contain web bugs which are inline content from an external server like images. When the email is opened, the server can notify a third party, posing a privacy risk. This can confirm that the email address is active and show when the email was read, making the address a target for future attacks.
HTML emails require email programs to use engines to parse, render and display the content. This can create more security vulnerabilities, cause denial of service attacks or result in low performance on older computers.
During times of increased network threats, the US Department of Defense converts all incoming HTML emails to plain text for added security.
The multipart format is meant to show the same content in different ways but it’s sometimes misused. Some email spammers exploit this by placing harmless content in the text part and the spam in the HTML part, tricking spam filters into thinking the email is legitimate.
Because of this tactic, most email spam is sent in HTML, so spam filters may assign higher spam scores to HTML messages.
In 2018, a severe vulnerability called EFAIL was discovered which could expose the content of encrypted HTML emails to attackers.
