1996: HTML vs. Plain Text: How Rich Email Won (and the Backlash)

For the first two decades of its existence, email was text. Plain, unformatted, monospaced text. No bold, no italic, no colors, no images, no fonts. Just words, line by line, in whatever typeface the recipient’s terminal or email client happened to use. It was functional, universal, and — to the marketing world — completely unacceptable. The introduction of HTML email in the mid-1990s split the email world into two camps that have been arguing ever since: those who see rich formatting as a necessary evolution and those who see it as an abomination.

The Plain Text Era

Early email was plain text by necessity. The systems that carried email — SMTP, POP3, and the email clients of the 1970s and 1980s — were designed for ASCII text. The MIME standard, introduced in 1991, added support for attachments and non-ASCII character sets, but the body of an email remained text.

Plain text email had a stark elegance. Messages were lightweight — a few kilobytes at most. They rendered identically on every system. They were accessible to screen readers and compatible with any email client, from a Unix terminal to a mainframe to a personal computer. There was no question of how a plain text email would look when it arrived — it would look like text.

The formatting options available in plain text were minimal: line breaks, spacing, and various ASCII conventions. Emphasis was conveyed with asterisks (important) or underscores (emphasis). Lists used hyphens or asterisks. Quotations were marked with the > character. These conventions evolved organically in the email and Usenet communities and remain in use today, having influenced the design of Markdown and similar lightweight markup languages.

The HTML Arrival

HTML email arrived in the mid-1990s, piggybacking on the web revolution. If browsers could render rich, formatted documents, why couldn’t email clients? The MIME standard already supported different content types — extending it to include text/html alongside text/plain was technically straightforward.

Netscape Messenger was among the first major email clients to support HTML rendering, followed quickly by Microsoft Outlook and Outlook Express. Hotmail, launched in 1996 as one of the first webmail services, displayed emails in a web browser that natively understood HTML. The technical barriers to rich email were falling.

For marketers, HTML email was revolutionary. Suddenly, emails could include brand logos, product images, colored text, formatted tables, and designed layouts. A marketing email could look like a printed brochure or a web page. The visual possibilities were transformative, and the marketing industry adopted HTML email with enthusiasm.

The Holy War

The introduction of HTML email triggered a debate that, three decades later, has not been resolved. The arguments on each side are well-established and passionately held.

The anti-HTML camp argued that HTML email was a solution in search of a problem. Plain text communicated information efficiently without the overhead of HTML rendering. HTML emails were larger, slower to download (a significant issue on dial-up connections), and rendered inconsistently across different email clients. More seriously, HTML provided an attack surface: embedded scripts, malicious links disguised as buttons, and tracking pixels all depended on HTML. Plain text was inherently more secure.

The pro-HTML camp argued that visual design improved communication. Formatting — headers, bullet points, bold text, images — made emails easier to scan and understand. Marketing emails needed visual branding to be effective. Modern connections could handle the additional file size. And security concerns could be addressed through better rendering engines rather than abandoning rich content entirely.

The debate was particularly fierce in technical communities. The Linux kernel mailing list, one of the most important email-based collaboration platforms in software development, famously insisted on plain text. Linus Torvalds, Linux’s creator, expressed his views on HTML email with characteristic directness. Many open-source projects and technical organizations maintained plain-text-only policies.

The Rendering Nightmare

For those who embraced HTML email, a new problem emerged: rendering consistency. Or rather, the complete lack of it.

Web browsers had spent years converging on shared rendering standards. By the 2000s, a well-coded web page would look roughly similar across Chrome, Firefox, Safari, and even Internet Explorer. Email clients never achieved this convergence.

The rendering disaster reached its peak when Microsoft Outlook 2007 switched from using Internet Explorer’s rendering engine (which was reasonably capable) to using Microsoft Word’s rendering engine. This decision — apparently motivated by a desire for better HTML authoring within Outlook — broke many CSS properties that email designers had relied on. Floats, background images, certain padding and margin behaviors, and many CSS layout techniques simply stopped working in Outlook.

Since Outlook had enormous market share in corporate environments, email designers couldn’t ignore it. They were forced to use table-based layouts — a technique web developers had abandoned years earlier — because HTML tables were the only layout mechanism that worked consistently across all email clients.

This is still true today. Email HTML is fundamentally stuck in the early 2000s, using techniques that web developers consider archaic, because the email client rendering landscape never standardized. An HTML email in 2026 is written using tables, inline CSS, and defensive coding techniques that would embarrass a web developer. The difference between what’s possible on the web and what’s reliable in email is vast and shows no sign of closing.

The Security Dimension

HTML email introduced security vulnerabilities that plain text never had. Early HTML emails could include JavaScript, which email clients would execute — a practice that was eventually disabled by all major clients after it was predictably exploited. But HTML continued to enable threats that plain text couldn’t.

Phishing attacks depend heavily on HTML. The ability to display a link that says “Click here to verify your Bank of America account” while actually linking to a malicious site is only possible in HTML. In plain text, URLs are visible — what you see is what you get. In HTML, the displayed text and the actual URL can be completely different.

Tracking pixels, as discussed elsewhere in this timeline, are an HTML-only technology. The ability to monitor email opens through invisible images requires HTML rendering. Plain text emails cannot track opens.

The Modern Compromise

The email world eventually settled into a pragmatic compromise. Marketing and promotional emails are almost universally HTML, with rich designs, images, and formatted layouts. Business correspondence varies — some organizations use HTML templates with branding, others use plain text or minimal formatting. Personal email defaults to whatever the email client provides, which is usually basic HTML.

Most email clients now support “multipart” messages that include both an HTML version and a plain text version. The recipient’s client displays whichever version it’s configured to prefer. This accommodation satisfies both camps in theory, though in practice, many senders include a plain text version that’s an afterthought — an auto-generated text dump of the HTML content with little attention to readability.

The Enduring Divide

The HTML vs. plain text debate reflects deeper values. Plain text advocates value simplicity, universality, security, and respect for the recipient’s bandwidth and attention. HTML advocates value visual communication, branding, design, and the ability to create engaging, scannable content.

Both sides are right. The best format depends on the context. A marketing newsletter benefits from visual design. A security advisory is better in plain text. A personal message doesn’t need a branded header and footer.

What’s clear is that both formats will persist. HTML email isn’t going away — the marketing industry depends on it. Plain text isn’t going away either — developers, security professionals, and privacy-conscious users will continue to prefer it. The holy war has settled into a cold peace, with each side occupying its territory and occasionally lobbing arguments across the border.

Infographic

Share this visual summary. Right-click to save.

Frequently Asked Questions

When did HTML email become common?

HTML email became technically possible in the mid-1990s when email clients like Netscape Messenger and Microsoft Outlook began supporting HTML rendering. Hotmail, launched in 1996, helped popularize HTML formatting in webmail. By the early 2000s, HTML email was the dominant format for marketing emails, though plain text remained common for personal and business correspondence.

Why do some people still prefer plain text email?

Plain text advocates cite several advantages: it's universally compatible across all email clients, it has no security vulnerabilities (no embedded scripts, tracking pixels, or malicious HTML), it loads instantly on any connection, it's accessible to screen readers, and it forces writers to focus on content rather than formatting. Many developers, security professionals, and Linux users prefer plain text.

What makes HTML email rendering so difficult?

Unlike web browsers, which follow shared rendering standards, email clients each render HTML differently. Outlook uses Microsoft Word's rendering engine, which doesn't support many modern CSS properties. Gmail strips certain CSS. Apple Mail renders differently from iOS Mail. There is no universal email HTML standard, forcing email developers to write code that works across dozens of different rendering engines simultaneously.