Updated · 6 min read
Plain-text email versions: why they still matter in 2026
Nobody reads plain-text emails any more — except screen readers, deliverability filters, enterprise mail gateways, and the one user in your program whose Gmail settings somehow ended up in text-only mode. The plain-text alternative is small, invisible infrastructure that most ESPs generate automatically (badly) and most programs ignore (wrongly). Here's why it matters and how to make the auto-generated version actually work.
Justin Williames
Founder, Orbit · 10+ years in lifecycle marketing
Why the plain-text version still matters
Email has been a multipart/alternative format since the 1990s. Every email can carry both an HTML version and a plain-text version; the recipient's client chooses which to render. In 2026, virtually all clients render HTML by default. So why care about the plain-text version?
1. Deliverability signal. Spam filters check whether a multipart email has both parts. Emails with only HTML and no text alternative score as slightly more suspicious (real senders typically provide both). The effect is small but non-zero.
2. Accessibility. Some screen-reader users configure mail clients to prefer text-only. Poorly-converted plain-text versions make these users' experience of your email substantially worse.
3. Enterprise mail gateways. Some corporate mail systems strip HTML or render text-only by default for security. Your email becomes whatever the plain-text version says.
4. Very old or minimal clients. Apple Watch native mail, some feature-phone mail clients, text-focused power-user configurations. A small audience, but one that's often technical and influential.
The plain-text version is infrastructure. Nobody notices it when it's right; everybody notices when it's broken. The auto-generated version is broken in most programs.
What auto-generation gets wrong
Most ESPs generate plain-text versions by stripping HTML tags and collapsing whitespace. The output has predictable problems:
Bare URLs everywhere. Every link in your HTML becomes a long URL in the plain-text version. "View our latest post" becomes "https://brand.com/blog/latest-post?utm_source=email&utm_medium=newsletter&utm_campaign=2026-04". Unreadable.
Alt text as body text. Images become their alt text inline. If your alt text is decorative ("[Brand] logo", "Decorative divider"), it pollutes the reading flow.
Lost structure. Headings, bullet lists, and tables flatten. A nicely structured HTML email becomes a wall of text with no visible hierarchy.
Preheader duplication. The preheader often gets duplicated at the top because it's an HTML element that's technically visible. Auto-generation picks it up.
How to write a good plain-text version
Most ESPs let you override the auto-generated plain-text with a custom version. The effort is modest and the quality gain is significant. Rules for a good plain-text version:
1. Rewrite for plain-text reading. It's not the HTML email with tags stripped — it's a text email written for text readers. Shorter, tighter, clearer structure via line breaks and indentation.
2. Convert links to readable format. "Read the full article: https://brand.com/article" not "https://brand.com/article?utm=...". Use shortened or clean URLs; the text user can still click or copy them.
3. Preserve structure via formatting. Use blank lines between sections. Use dashes or hashes for lightweight headings. Use simple bullet-style (- item) for lists. Structure survives; the email stays readable.
4. Mirror the information architecture. Subject line, opening, main content, CTA, sign-off. Same structure as HTML; just text.
5. Include the unsubscribe link in text. "Unsubscribe: https://brand.com/unsub?token=..." — respect the user who's opening the text version as much as the HTML user.
Where the effort pays off
A well-crafted plain-text version is most valuable for:
Transactional emails. Users sometimes view order confirmations, receipts, and security alerts in text. A readable plain-text receipt is a better user experience than HTML-stripped soup.
High-deliverability-stakes sends. Newsletter, broadcast campaigns. The deliverability signal of a clean multipart email is small but worth capturing.
Accessibility-focused programs. If your audience skews toward enterprise or accessibility-sensitive contexts, plain-text quality affects real users directly.
For small programs or informal marketing emails, the auto-generated version is probably fine. The cost/benefit turns positive as volume increases and audience sensitivity rises.
Testing plain-text
,
treats plain-text version review as part of template QA for high-stakes sends — transactional, newsletters, program-level templates that'll send to many users. One-off campaigns can usually rely on auto-generation.
Frequently asked questions
- Do I really need a plain-text version?
- Technically, no — emails work without it. Practically, yes — multipart emails score better on deliverability, render correctly for accessibility tooling, and work in edge-case client configurations. Every ESP includes it by default; the question is whether to improve the auto-generated version or leave it as-is.
- How much does plain-text quality affect deliverability?
- Marginal but positive. Spam filters include 'has valid multipart structure' as one of many signals; a missing or malformed plain-text part slightly increases spam score. Not a dominant factor, but real. Programs with borderline deliverability should fix this; programs with healthy deliverability will see minimal change.
- Can I auto-generate the plain-text version?
- Yes — that's the default. The question is whether the auto-generated version is good enough. For most programs, it's mediocre (bare URLs, stripped structure). For broadcast and transactional, consider overriding with a hand-written version. For one-off campaigns and internal sends, auto-generation is fine.
- What should a plain-text email look like?
- Plain prose with structure preserved via line breaks, dashes, and indentation. Hyperlinks in readable format ('Read more: https://example.com/article'). Same subject line, similar CTAs, similar structure to HTML. Not a code-dump; a text email written for text readers.
- Should the plain-text include images or logos?
- No — they wouldn't render. Reference them as text where meaningful: 'Photo of [product name]' at the point where the image would appear, if the image conveys meaningful information. For decorative images, skip entirely.
- Is plain-text still relevant for mobile?
- Mostly not — mobile clients render HTML. But users on Apple Watch and some screen-reader-integrated mobile configurations do see text. These are edge cases; the plain-text version's main value isn't mobile readership but deliverability and accessibility infrastructure.
Related guides
Browse all →Preheader text: the second subject line most programs ignore
Preheader text is the snippet shown next to the subject line in the inbox preview. Done well, it doubles your hook. Done badly, it says 'View this email in your browser'. Here's how to write preheaders that earn the open.
Email dark mode: the four render modes and how to not break any of them
Dark mode in email isn't one thing — it's four different render behaviours depending on the client. Design without knowing which mode you're hitting and your emails will look broken to 40% of your audience. Here's what each client does.
Mobile email design: 65% of opens are on a phone — design for that
Two-thirds of email is opened on mobile. Most email designs still start with a desktop layout and hope it collapses well. Here's the mobile-first rules that reliably produce emails that read, click, and convert on a phone.
Email accessibility: the seven rules that make your emails readable by everyone
Email accessibility isn't a compliance tax — it's the difference between reaching 100% of your audience and the 85% who have easy sight, steady hands, and full-volume screens. Here are the seven rules that cover 90% of what actually matters.
Transactional email anatomy: the five sections every transactional needs
Transactional emails get opened at 3–5× the rate of marketing and carry more brand signal per send. Most programs treat them as ops artefacts and miss the leverage. Here's the five-section template that works for every transactional type.
Brand voice in lifecycle: how to sound like you — not the generic SaaS CRM voice
Lifecycle emails drift toward a generic 'polished SaaS CRM voice' because it's the default pattern in every template library and every agency deliverable. Here's how to actually write in your brand's voice across an entire lifecycle program.
Found this useful? Share it with your team.