Every HTML newsletter you send includes a hidden twin: the plain text version. You’ve probably never looked at it. Your ESP auto-generates it, strips out the formatting, and sends it along for the ride. Job done.
Except it’s not done. That plain text version isn’t just a technical formality for ancient email clients. It’s read by spam filters before your message hits the inbox. It’s served to subscribers using assistive technology. And roughly 10–15% of your list has their client set to display plain text by default, either for bandwidth, security, or simple preference.
When your plain text version is broken, illegible, or littered with rendering artefacts, you’re not just offering a poor experience to a minority of readers. You’re sending mixed signals to the infrastructure that decides whether your newsletter gets delivered at all.
What auto-generated plain text actually looks like
Most platforms generate plain text by stripping HTML tags and guessing at structure. The results are predictably bad. Link URLs appear in full, often mid-sentence. Navigation elements, social icons, and footer legalese appear in random order. Image alt text may vanish entirely, leaving contextless gaps. If you’ve used buttons, they often render as naked URLs with no explanatory text.
Even worse: if your HTML uses tables for layout (still common in email templates), the plain text version can scramble reading order completely. A two-column layout might interleave sentences from both columns, making the whole message unintelligible.
Spam filters notice. A newsletter where the plain text version is drastically shorter, structurally garbled, or filled with broken formatting signals a sender who isn’t paying attention to technical hygiene. It’s a small red flag, but reputation is built from small flags.
Why accessibility isn’t optional
Screen readers don’t parse your beautifully art-directed HTML. They consume the plain text version, or read the HTML semantically if no plain text exists. If your auto-generated version is a mess, you’ve just made your newsletter inaccessible to blind and low-vision subscribers.
This isn’t a niche concern. Assistive technology users are overrepresented among newsletter audiences, particularly in professional and educational niches. They’re also among your most loyal readers—if you don’t chase them away with illegible formatting in the first three sends.
Even subscribers without disabilities sometimes switch to plain text mode when travelling, on poor connections, or using privacy-focused clients that block remote images by default. If your plain text version assumes they’ll see the HTML, you’ve lost them.
How to fix it without doubling your workload
Start by actually looking at the plain text version your platform generates. Most ESPs show it in the send preview. If yours doesn’t, send yourself a test and check your client’s view options. What you’re looking for: legibility, logical reading order, and whether calls-to-action still make sense.
If it’s a disaster, you have two options. First: clean up your HTML structure. Use semantic headings, keep layouts simple, avoid complex tables, and write descriptive link text instead of “click here.” Many rendering problems fix themselves when the source HTML is cleaner.
Second: write a custom plain text version. Most platforms let you override the auto-generated one. This sounds like extra work, but it’s faster than you think. You’re not redesigning the newsletter—you’re just ensuring the message makes sense in a linear, unformatted reading. Strip theNav. Shorten footer legalese. Make link context explicit. A tight 400-word plain text version often works better than a bloated 800-word HTML piece.
One operator trick: use your plain text version as an editing tool. If the message doesn’t hold up without formatting, images, and design crutches, the HTML probably isn’t as clear as you think.
Test it like you test subject lines
You’d never send a newsletter without checking the subject line. The plain text version deserves the same scrutiny. Build it into your pre-send checklist: preview the plain text, read it top to bottom, verify links make sense in context.
If you’re running a team, assign plain text QA to someone who isn’t the designer or writer. Fresh eyes catch the assumptions and context gaps that slip through when you’ve been staring at the HTML for an hour.
And if you’re using dynamic content blocks, personalisation, or conditional sections, test the plain text version with different audience segments. Auto-generation handles conditionals poorly, and you may discover entire sections rendering out of order.
Take five minutes this week: pull up your last three sends and look at the plain text versions. If you wince, your subscribers already did. Fix it before your next send, and keep fixing it. The readers who notice won’t say anything—they’ll just stay subscribed.