HTML vs Plain Text Emails: When to Use Each
What each format costs in deliverability, tracking and effort, and the hybrid most senders should actually use.
On this page
The short version
- This is not a binary. Nearly every email should be sent as a multipart message carrying both, and the real decision is what the HTML version looks like.
- Plain-text-styled HTML — minimal markup, no images, no branding furniture — often outperforms designed email on lists that expect a personal sender, and underperforms on retail lists that do not.
- A missing or auto-generated plain text part is a small deliverability signal and a real accessibility one.
The question is usually asked as a choice and is not one. A properly constructed email is multipart: an HTML part and a plain text part, both present, with the client picking. Sending HTML only, or letting your platform auto-generate a plain text part from your markup, is where the problems start.
The decision that actually matters is what the HTML part looks like — a designed template with a header, images and branding, or something that reads as though a person typed it.
Multipart alternative
One message carrying two versions of the same content. The client displays whichever it prefers or the recipient has configured. Both parts should say the same thing — a plain text part that is a broken transcription of the HTML is worse than a short honest one.
What each format costs you
Designed HTML buys structure, branding and measurable clicks on obvious buttons. It costs build time, rendering risk, and a small amount of the intimacy that makes a message feel written rather than published.
Plain-text-styled HTML buys the opposite: it reads as personal, invites replies, renders identically everywhere, and takes minutes to produce. It costs you image tracking for open rate, visual hierarchy, and the ability to look like a brand when that is what the audience expects.
The trade, itemised
| Designed HTML | Plain-text style | |
|---|---|---|
| Build time | Hours per template | Minutes |
| Rendering risk | Real, needs testing | Effectively none |
| Reads as | Published | Written |
| Reply rate | Low | Noticeably higher |
| Open tracking | Works via pixel | Works, if you keep one image |
| Click tracking | Works | Works |
| Suits | Retail, product, announcement | Newsletters, B2B, founder-voice |
| Accessibility | Depends entirely on the build | Good by default |
The reply rate row is the underrated one. Replies are among the strongest positive engagement signals a mailbox provider can observe, and a message that looks like a broadcast does not get them.
The auto-generated plain text problem
Most platforms will generate the plain text part for you by stripping tags. The output is frequently poor: navigation labels stranded at the top, a run of bare URLs where buttons were, alt text scattered mid-sentence, and the legal footer occupying half the message.
Anyone reading that part — screen reader users, people who have configured plain text, some corporate clients — receives that version and no other. Writing it by hand takes a few minutes and is one of the few accessibility improvements that is also a deliverability improvement.
Does plain text improve deliverability?
Not on its own, and the claim is widespread enough to be worth addressing directly. Filters are not looking for HTML and penalising it — the overwhelming majority of legitimate commercial email is HTML.
What is real is narrower: a very high image-to-text ratio, an image-only email with almost no live text, and a missing plain text part are all weak negative signals. A well-built HTML email with real text content and a hand-written plain text part carries none of them.
The indirect effect is larger than the direct one. Plain-text-styled email gets more replies, and replies feed the engagement signals that determine placement over time.
Whichever you send
- A plain text part exists and was written, not generated
- Both parts say the same thing and carry the same links
- The plain text part has the unsubscribe instruction in it
- Image-to-text ratio is not extreme
- The email is not a single image with a link on it
Frequently asked questions
Will plain-text-style hurt our brand?
On a retail list where subscribers expect product imagery, probably. On a newsletter written by a named person, the opposite — the designed version is what undermines the voice. Match the format to what the list already believes it is receiving.
Can I track opens in a plain-text-styled email?
Yes, if you keep one small image — usually the tracking pixel itself. A genuinely plain text part carries no images and therefore no open tracking, which is one reason plain-text-styled HTML is more common than true plain text.
Should transactional email be plain text?
It should be simple, which is not the same thing. A receipt needs structure — a table of line items is clearer than a list of sentences. Keep the design minimal and the information dense.