Updated · 6 min read
Plain-text email versions: why they still matter in 2026
Picture a corporate inbox somewhere — bank, government department, big-pharma compliance team — where the IT policy strips HTML out of every incoming email before the recipient ever sees it. Your beautiful campaign lands as whatever the plain-text version says. If that version is a wall of stripped tags and tracking URLs, that's the email those users got. The plain-text alternative is small, invisible infrastructure that most ESPs (email service providers — the platform you send from, like Braze or Klaviyo) generate automatically, badly, and most programs ignore. Here's why it matters and how to make the auto-generated version actually readable.
By Justin Williames
Founder, Orbit · 10+ years in lifecycle marketing
The audience you forgot you had
Every email you send is technically two emails. Since the 1990s, email has used a format called multipart/alternative — the message carries an HTML version and a plain-text version side by side, and the recipient's mail client picks which one to render. Almost everyone gets the HTML version. So why care about the other one at all?
Because the people who get the text one are not random. Four audiences read it, and three of them matter for reasons that have nothing to do with the user.
1. Spam filters use it as a deliverability signal. Mailbox providers — Gmail, Outlook, Yahoo, the systems deciding whether your email lands in inbox or spam — check whether a multipart email actually has both parts. HTML-only with no text alternative scores marginally more suspicious because real senders typically ship both. The effect is small but non-zero. Borderline reputation? Fix this. Healthy reputation? You'll barely notice.
2. Screen-reader users sometimes prefer it. Some configure their mail client to render text-only. A poorly converted plain-text version makes their experience meaningfully worse than an HTML user's — and that's on you, not them.
3. Enterprise mail gateways strip HTML for security. Corporate mail systems sometimes render text-only by default. Your email becomes whatever the plain-text version says. If the auto-generated version is a mess, the corporate user is reading a mess.
4. Old or minimal clients render only text. Apple Watch native mail. Some feature-phone clients. Text-focused power-user setups. Small audience. Often technical, often influential. Worth not insulting.
The plain-text version is infrastructure. Nobody notices it when it's right; everybody notices when it's broken. And the auto-generated version is broken in most programs.
What your ESP is shipping when you're not looking
Most ESPs build the plain-text version with the laziest algorithm available: strip the HTML tags, collapse the whitespace, ship it. The output has four predictable failure modes — every one of them visible the second you actually look at the text part of one of your sends.
Bare URLs everywhere. Every link in your HTML becomes a long URL in the text version. "View our latest post" turns into https://brand.com/blog/latest-post?utm_source=email&utm_medium=newsletter&utm_campaign=2026-04. Unreadable. Worse, it looks untrustworthy — phishing emails look exactly like that.
Alt text as body text. Images convert to their alt text inline. Alt text is the description that screen readers announce in place of an image. If yours is properly decorative — "[Brand] logo", "Decorative divider" — it pollutes the reading flow with noise that shouldn't be there.
Lost structure. Headings, bullet lists, tables all flatten. A nicely structured HTML email becomes a wall of text with no visible hierarchy. Everything looks equally important, which means nothing does.
Preheader duplication. The preheader — the short preview line that shows next to the subject in the inbox — usually duplicates at the top of the body, because it's technically a visible HTML element. Auto-generation picks it up and the text version opens with the same line twice.
Writing the version your readers actually want
Most ESPs let you override the auto-generated version with a hand-written one. The effort is modest. The quality gain is significant. Here's the rule set.
1. Rewrite for plain-text reading, don't convert. A good plain-text version isn't the HTML email with tags stripped. It's a text email written for people reading text. Tighter copy, cleaner structure, line breaks and indentation doing the work CSS does in the HTML version.
2. Convert links to a readable format. "Read the full article: https://brand.com/article" reads cleanly. A 200-character URL with seven tracking parameters doesn't. Use shortened or clean URLs where you can. Text users still click or copy them — they just need to be able to see what they're clicking.
3. Preserve structure with formatting characters. Blank lines between sections. Dashes or hashes for lightweight headings. Simple bullets (- item) for lists. Structure survives. The email stays scannable.
4. Mirror the information architecture. Subject line, opening, main content, CTA, sign-off — same flow as HTML, just text. A reader on the text version should be able to follow the same path through the email as a reader on the HTML version.
5. Include the unsubscribe link in text. "Unsubscribe: https://brand.com/unsub?token=...". Respect the text reader as much as the HTML reader. Regulations — CAN-SPAM in the US, GDPR in the EU, the Spam Act in Australia — require an unsubscribe mechanism in every commercial email, regardless of how it gets rendered.
Images get no equivalent in text. Where an image carries meaningful information, reference it as a short note ("Photo of [product name]") at the point where it would appear. For decorative images, skip entirely. No logos, no spacers, no alt text doubling as body copy — those add nothing on the text side.
When this is worth your time, and when it isn't
Hand-writing the plain-text version isn't free. Here's where the effort actually pays back.
Transactional emails. Order confirmations, receipts, security alerts, password resets. Users do view these in text — sometimes from a corporate gateway, sometimes from a watch, sometimes because they searched their archive years later. And these are the emails the user is often reading under stress: a fraud alert, a locked account. Make them legible.
High-deliverability-stakes sends. Newsletters and broadcast campaigns going to big lists. The deliverability signal from a clean multipart structure is small per send, but it compounds at volume. Worth capturing.
Accessibility-focused programs. If your audience skews enterprise or has accessibility-sensitive context — government, healthcare, B2B SaaS sold into regulated industries — plain-text quality is part of the actual user experience. Treat it as part of the template, not an afterthought.
For small programs and one-off campaigns, auto-generation is probably fine. The cost-benefit turns positive as volume rises and audience sensitivity rises. Below that line, your ESP's default is good enough. Don't hand-craft text versions on a hobby newsletter.
Actually look at the thing you're shipping
Most teams have never opened the plain-text version of one of their own emails. That is the single largest reason most plain-text versions are bad.
treats plain-text review as part of template QA for high-stakes sends — transactional, newsletters, anything going to many users. One-off campaigns can usually coast on auto-generation without guilt. The decision rule: if more than ten thousand people are getting this email, or if the sender reputation matters, look at the text version before you send.
Read to the end
Scroll to the bottom of the guide — we'll tick it on your reading path automatically.
This guide is backed by an Orbit skill
Related guides
Browse allTransactional email anatomy: the five sections every transactional needs
Transactional emails — receipts, password resets, shipping updates — open at 3–5x the rate of marketing and carry more brand signal per send than anything else in the program. Most teams treat them as ops artefacts and miss the leverage entirely. Here's the five-section anatomy that works across every transactional type.
Transactional emails: the highest-engagement messages you ignore
Order confirmations, password resets, receipts, shipping updates. Transactional emails post open rates two to three times higher than marketing sends — and most lifecycle teams have never touched them. Effort is going to the wrong place.
Why Gmail clips emails at 102KB (and how to stop it)
Gmail has been clipping emails over 102KB since 2013. The 'View entire message' link almost nobody clicks is where your unsubscribe, secondary CTA, and legal footer go to die. Here's how bytes actually pile up and the discipline that keeps every send under the threshold.
Preheader text: the second subject line most programs ignore
The preheader is the snippet shown next to the subject line in the inbox preview. Treat it like a second subject line and you double your hook. Treat it like an afterthought and it says 'View this email in your browser'. Here's how to write preheaders that actually earn the open.
Personalisation that doesn't feel creepy
There's a line between personalisation that earns trust and personalisation that breaks it. It's not where most people think it is — it's about how you signal what you know, not what you know. Here's the line, how programs cross it without noticing, and the patterns that keep you on the right side.
Subject line anatomy: the four parts every line that performs shares
Most subject-line advice is decoration tips — emoji, length, numbers. The lines that actually get opened share a structural pattern. Four parts in a specific order, the three distortions that ruin it, and the four rules that keep A/B tests honest.
Found this useful? Share it with your team.
Use this in Claude
Run this methodology inside your Claude sessions.
Orbit turns every guide on this site into an executable Claude skill — 63 lifecycle methodologies, 91 MCP tools, native Braze integration. Free for everyone.