HTML to Plain Text for Email: Why It Still Matters in 2026
Almost every modern email client renders HTML, so why does the plain-text part still matter? Because the recipient isn't always on a modern email client. Smart watches, screen readers, accessibility-mode mail clients, voice assistants reading email aloud, plain-text-only corporate gateways, and email previews in Slack or Teams all fall back to the plain-text part. About 2–4% of recipients across most B2B audiences receive your email as plain text only.
And there's a deliverability dimension: spam filters look for the absence of a plain-text part as a weak negative signal. An email that ships only an HTML body, with no multipart/alternative plain-text counterpart, looks slightly more like a phishing template than a legitimate marketing email. Most ESPs auto-generate one for you if you don't supply one — but the auto-generated version is often ugly and leaks HTML artifacts.
This guide walks through the MIME structure that makes plain-text fallbacks work, what conversion strips and preserves, structural patterns that survive cleanly, common mistakes that break the plain-text version, and a free in-browser converter that produces well-formatted plain text from any HTML email source.
What you will learn: The MIME multipart/alternative structure for email, what HTML-to-plain-text conversion strips (tags, CSS, images) and preserves (links, line breaks, lists, headings), markdown-flavored output, common mistakes (auto-generated mess, long URLs, no line wrapping), structural HTML patterns that survive conversion cleanly, modern ESP behavior, and how to use the free MiN8T Plain-Text Converter.
1 Why a Plain-Text Version Still Matters
Almost every modern email client renders HTML. So why does the plain-text part still matter? Because the recipient isn't always reading on a modern email client. Smart watches, screen readers, accessibility-mode email clients, voice assistants reading email aloud, plain-text-only corporate gateways, and email previews in Slack / Teams notifications all fall back to the plain-text part. About 2–4% of recipients across most B2B audiences receive your email as plain text only.
And there's a deliverability dimension: spam filters look for the absence of a plain-text part as a weak negative signal. An email that ships only an HTML body, with no multipart/alternative plain-text counterpart, looks slightly more like a phishing template than a legitimate marketing email. Most ESPs will auto-generate a plain-text part for you if you don't supply one — but the auto-generated version is often ugly and leaks HTML artifacts.
And finally, the legal angle: CAN-SPAM compliance in the US doesn't strictly require plain-text, but accessibility regulations (WCAG, EU EAA) lean strongly on the recipient's ability to read your message in a format they can process. A plain-text fallback is the simplest way to meet that bar.
What this article walks through
The MIME multipart/alternative structure that makes plain-text fallbacks work, what HTML-to-plain-text conversion actually does (and what it strips), the structural patterns that survive conversion, common mistakes that break the plain-text version, and a free in-browser converter that produces well-formatted plain text from any HTML email source.
The plain-text part of your email is a 2–4% accessibility win, a deliverability nudge, and a free anti-phishing signal. Treat it as a deliverable, not an afterthought.
2 How multipart/alternative Works
An email is a MIME message. Its body is one or more parts, each with its own Content-Type header. multipart/alternative is the part type that says "here are multiple representations of the same content; the email client picks the one it can render best."
Content-Type: multipart/alternative; boundary="abc123"
--abc123
Content-Type: text/plain; charset=utf-8
[plain-text version of the email]
--abc123
Content-Type: text/html; charset=utf-8
[HTML version of the email]
--abc123--The MIME standard says clients should render the last part they understand. So a modern client picks HTML; a plain-text-only client picks plain-text. Both representations should convey the same meaning — otherwise you're shipping different content to different recipients depending on their client, which is a soft anti-spam signal and just rude.
What "the same meaning" actually means
The plain-text version doesn't need to be a literal character-for-character match. It needs to be the email's content, expressed without HTML. The headline becomes a line of text in caps or with a divider underneath. The CTA button becomes a line of text with a URL. The product grid becomes a bulleted list. The reader of the plain-text version should walk away with the same call-to-action and roughly the same information density.
Most ESPs handle the MIME wrapping for you
You don't usually edit MIME boundaries by hand. Mailchimp, Klaviyo, ESPs, and transactional services all wrap your HTML in a multipart/alternative envelope automatically; you provide the plain-text content and they assemble the rest. The work is in the plain-text content itself, not the wire format.
3 What Conversion Strips and What It Preserves
Reasonable HTML-to-plain-text conversion does roughly this:
Stripped:
- All HTML tags (<div>, <table>, <span>, <td>)
- All inline CSS (style attributes, <style> blocks)
- Image tags — replaced with the alt text if present, or dropped if not
- Comments, conditional comments, <!--[if mso]--> blocks
- Tracking pixels and other invisible elements
Preserved:
- Anchor tags — converted to "link text (URL)" format, so the URL is visible to the reader
- Line-break structure — <br> becomes a newline, <p> becomes a blank line above and below
- List items — <li> becomes a bullet (* or ·) with proper indentation
- Headings — <h1> through <h6> get visual weight via underlines (===) or capitalization
- The actual text content — obviously
The link-handling pattern
The standard convention is: Click here to read more (https://example.com/article-link). Anchor text first, URL in parens immediately after. Some converters use bracketed format Click here [https://example.com] — that also works. What you want to avoid is dropping the URL entirely (the reader can't follow it) or putting the raw URL where the anchor text was (looks ugly).
Markdown-style fallbacks
For fancier formatting, some converters output Markdown-flavored plain text: headings as # / ## prefixes, bold as *asterisks*, links as [text](url). Markdown is technically still plain text and is more readable than raw HTML conversion. The downside: not every plain-text reader knows Markdown, so to a reader who doesn't, those asterisks and brackets look weird.
The pragmatic call: standard plain-text conversion is fine for most B2C and B2B work. Markdown-flavored conversion is a nice touch for developer audiences and technical newsletters who'll appreciate the structure.
4 Common Mistakes
1. Letting the ESP auto-generate it
Most ESPs auto-generate a plain-text version from your HTML if you don't supply one. The output is usually a stream of leftover HTML artifacts: button labels and their hidden alt text rendered twice, table cells run together as one line, social-icon alt text dumped in a row at the footer. Always supply your own plain-text version unless you've actually inspected the auto-generated output and confirmed it's readable.
2. URL formatting that flows badly
A long URL in the middle of a paragraph wraps mid-URL on a phone screen, looking like:
Click here to read more (https://example.com/2026/q1/blog
post/very-long-slug-that-wraps?utm=...).The line break inside the URL breaks click-through — the reader can't easily copy-paste it. Either put the URL on its own line, or put the URL right after the text with a line break before the next paragraph.
3. No line wrapping
Plain-text emails should hard-wrap at 72–78 characters per line. Above that, plain-text-only readers (smart watches, terminal email clients) horizontally scroll, which feels broken. Most converters wrap automatically; if you're hand-writing the plain-text version, run it through a wrap tool.
4. Forgetting the unsubscribe link in plain text
Legal requirement (CAN-SPAM, GDPR). The unsubscribe link must be present and clickable in the plain-text version. ESPs usually inject it into the auto-generated plain-text. If you supply your own plain-text without an unsubscribe link, you're now the one responsible for compliance.
5. Different content in plain text vs HTML
Spam filters notice when the plain-text and HTML parts say substantially different things — it's a phishing pattern. Keep the content roughly equivalent. The plain-text version can be shorter and less stylized, but should cover the same message and CTA.
5 Structural Patterns That Survive Conversion
If you write your HTML email with plain-text in mind, the conversion is much cleaner.
Use semantic HTML, even though Outlook makes you use tables
Tables are required for layout in email; that's fine. But within table cells, use <p> for paragraphs, <ul>/<li> for lists, <h1>/<h2> for headings. Don't use <br><br> as a paragraph break or <span style="font-size:24px;font-weight:bold"> as a heading. The semantic markup gives the converter signals; the styled-span markup loses them.
Write meaningful alt text on every image
The alt text becomes the plain-text representation of the image. "Hero image of a product on a white background" tells a plain-text reader nothing useful; "Spring 2026 sneakers, $89" tells them what they need to know. Alt text doubles as accessibility text and as plain-text fallback — one piece of work, two payoffs.
Don't use images for critical text
"Save 20% this weekend" rendered as an image becomes "" (empty alt) or "save-20-image.png" (file name leaked into alt) or a useless generic alt in plain-text. Render headlines and CTAs as live HTML text whenever possible.
The pattern for buttons
The HTML button is a styled anchor. In plain-text it should render as the anchor text plus the URL: Read More (https://example.com/article). If you're rendering the button via VML/conditional-comment trickery for Outlook, make sure the modern <a> half is the one with the human-readable anchor text — that's what the converter picks up.
6 Modern Tooling and ESP Behavior
The conversion problem isn't new; the tooling is mature.
Mailchimp, Klaviyo, et al.
All major ESPs auto-generate plain-text from your HTML. Most also let you override the auto-generated version with your own custom plain-text. The override is the right pattern — trust the ESP for the wrapping (MIME boundaries, character encoding) but write the plain-text content yourself.
Transactional services (Postmark, SendGrid, Resend)
Transactional senders typically expose two parameters: html and text. You can supply just html and get auto-conversion, supply just text and get a plain-text-only email, or supply both and get a multipart/alternative MIME message. For transactional email (password resets, order confirmations) the right pattern is to write both, by hand, since you control the template and want full quality on both halves.
The conversion library landscape
If you're building your own templating: html-to-text is the most-used Node library, has good defaults and configurable wrapping. html2text is the Python equivalent, supports Markdown output. BeautifulSoup + custom rules works for one-off conversions. The MiN8T Plain-Text Converter uses the same approach as html-to-text but runs entirely in the browser — paste in HTML, get plain-text out, no upload.
The auto-generated-vs-hand-written question
Hand-written plain-text is better; auto-generated is acceptable. The 80/20 here: auto-generate the plain-text from your HTML during template creation, then hand-edit the auto-generated output to fix the obvious problems (long URLs, wonky line breaks, dropped headings). 5 minutes of editing per template, applied across 100 sends, pays back many times over.
7 The 2026 Take
Plain-text isn't going anywhere. The wearable / voice / accessibility / corporate-gateway long tail of recipients who can only see the plain-text part keeps growing as the world adds more devices, not fewer.
Accessibility regulation is tightening
The EU Accessibility Act (June 2025), updated WCAG 2.2 guidance, and various US state-level laws are all moving in the direction of "your digital communications must be readable by users on assistive technology." Plain-text is the most reliable assistive-tech-friendly representation of an email; supplying a good one is a cheap way to be on the right side of those rules.
Spam-filter signals haven't gotten weaker
Gmail, Outlook, and Apple Mail filter inputs include "presence of a meaningful plain-text part." A multipart/alternative email with a real plain-text body looks more like a legitimate sender; an HTML-only email looks slightly more like a phishing template. Marginal effect, but free.
The new wrinkle: AI-summarized email
Apple Intelligence, Gmail's AI inbox-summary feature, and various third-party email AI assistants generate one-line summaries of incoming email. Some of them prefer the plain-text part as the input (it's smaller and parseable); others use the HTML. Either way, the AI's summary — which the recipient often reads instead of the email itself — is downstream of how clearly your message reads in plain language. Plain-text discipline is a forcing function for clear copy.
Use the free converter
The MiN8T Plain-Text Converter takes any HTML email source, strips the markup, formats links, wraps lines at 78 chars, and outputs clean plain text. Optional Markdown-flavored output for technical audiences. Runs entirely in the browser; no upload.
Plain-Text Generation Built In
MiN8T's editor generates a clean plain-text version of every email automatically — multipart/alternative MIME wrapping, properly-formatted links, hard-wrapped at 78 chars, with the unsubscribe link injected. Edit it in place if you want hand-tuned copy; trust the default if you don't.
Start Building for Free
