Skip to main content

Plain Text Email Generator

What it does

The Plain Text Email Generator converts an HTML email into a clean plain-text version suitable for the multipart/alternative part of an email send. It preserves links in text (url) form, word-wraps at the 72-character convention, strips styling and inline markup, and outputs text that reads naturally. Recipients whose clients can’t or won’t render HTML get the message intact, and spam filters that compare HTML against the plain-text alternative see content that matches.

Common situations

You’ve designed an HTML campaign and your ESP requires a plain-text version. Most ESPs auto-generate one, but the result is often mangled: link text disappears, paragraphs run together, formatting is lost. The generator gives you a cleaner version you can drop in as the alternative.

A campaign is hitting spam filters and you suspect the auto-generated plain text is one of the signals. Filters compare the HTML and plain-text alternates; if the plain text is empty, machine-mangled, or vastly different in content, the message looks suspicious. A coherent plain-text version reduces this signal.

You’re sending to an audience that includes a high proportion of plain-text readers: security-conscious users, command-line mail readers, accessibility-tool users, certain corporate environments where HTML is stripped at the gateway. They never see the HTML version; the plain text is the message.

You’re auditing accessibility. Some screen readers prefer the plain-text alternate when both are present; verifying it reads coherently is an accessibility check, not just a deliverability check.

You’ve been told to “always include a plain-text alternative” but have no clear process for it. The generator turns this from a vague best-practice into a concrete two-minute step before each send.

What you need to know

Email is delivered as MIME (Multipurpose Internet Mail Extensions). A modern marketing or transactional email is sent as multipart/alternative with two parts:

  • A text/html part: the styled version
  • A text/plain part: the fallback

The receiving client picks which to render. Most consumer clients (Gmail, Outlook, Apple Mail) render HTML by default. But the plain-text alternate matters for several reasons:

Spam filter signal: filters compare the two alternates. If they’re substantially different in content, length, or coherence, the message becomes suspicious. A common pattern in malicious mail is a benign plain-text part hiding a phishing HTML part; filters flag the discrepancy.

Plain-text-only readers: some users (corporate gateways, security-conscious individuals, command-line tools, accessibility tools) read the plain-text part exclusively. Auto-generated plain text often becomes incoherent for them.

Email forwarding: when an HTML email is forwarded, some clients quote only the plain-text version. Sending readable plain text means forwards remain readable.

Mobile bandwidth: rare today but historically relevant. Some mobile clients on slow connections preferred plain text.

The generator’s conversions:

  • Headings (h1–h6): rendered as the heading text on its own line, blank lines around it. h1 may be underlined with =, h2 with - (RFC-style), depending on options.
  • Paragraphs: text content with blank line between paragraphs. Word-wrapped at 72 characters by default, the email convention dating back to terminal widths.
  • Links: <a href="url">text</a> becomes text (url). The URL is preserved in parentheses so plain-text readers can copy and paste it. If the link text is the URL itself, deduplicated (no https://example.com (https://example.com)).
  • Lists: <ul> becomes - item per line; <ol> becomes 1. item per line.
  • Bold/italic: stripped (no Markdown-style asterisks added by default; most plain-text readers don’t expect them).
  • Tables: flattened to text, row by row. Tables don’t translate well to plain text; if your HTML relies heavily on tables for content layout, the plain-text version may be awkward.
  • Images: replaced with alt text in brackets [alt text], or removed if no alt text.
  • HTML entities: decoded (&amp; → &, &nbsp; → space).
  • Whitespace: collapsed sensibly. Multiple consecutive blank lines become one.

What the generator can’t do:

  • Reverse-engineer intent from styled HTML. If your HTML uses background colours and font sizes to convey hierarchy, plain text loses that hierarchy. Use semantic HTML (h1, h2, p) for both better accessibility and better plain-text conversion.
  • Preserve complex layout. Multi-column layouts, image-heavy designs, and decorative elements don’t translate. Plain text is linear; design accordingly if plain-text readability matters.

Word-wrap at 72 characters: a long-standing email convention. Old terminal-based mail readers had 80-column displays; 72 leaves room for quote-prefix characters (>) when forwarding. Modern clients reflow text anyway, so it’s mostly cosmetic, but staying close to the convention prevents weird breaks in clients that don’t reflow.

Frequently asked questions

Why does plain-text email matter in 2026?

Mostly because spam filters compare the alternates. Empty or auto-mangled plain-text triggers suspicion signals. Some readers do still consume plain-text exclusively (security-conscious users, accessibility tools, corporate gateways), but the deliverability signal is the bigger reason most senders care.

Doesn’t my ESP generate the plain-text version automatically?

Most do, but the output varies enormously. Some ESPs strip everything aggressively (links lost), some include all the HTML markup as text (raw HTML soup), some attempt heuristic rendering with mixed results. Check your ESP’s auto-generated output before relying on it; if it’s bad, generate manually.

What’s the right line width for plain-text emails?

72 characters is the convention (RFC 5322 effectively encourages staying under 80 for compatibility). Some senders use 78. Modern clients reflow text dynamically, so the exact number is less critical than it used to be, but staying close to convention avoids weird wrapping in less-modern clients.

Should I include URLs inline or only as link text?

Inline. The convention is text (url), readable for humans and copy-paste-able. Some senders put URLs only at the end (“[1] [2] [3]” with footnote-style references) but inline is more common and friendlier for screen readers.

Will plain-text emails look unprofessional?

To users who only see the HTML version, plain text is invisible. To users who see the plain text exclusively, the standard is “coherent and readable”, not “designed”. A clean plain-text alternative is professional in that context.

Can I include images in plain text?

No. Plain text by definition has no images. Use alt text in brackets [alt text] to tell readers what the image showed. If images are critical to your message, that’s a sign the HTML version is doing too much heavy lifting and accessibility may be at risk.

What if my email has tables?

Tables don’t translate well to plain text. Simple two-column tables can be approximated with tab-separated text, but anything with merged cells or complex layout becomes unreadable. Where possible, restructure data tables as labelled lists for the plain-text alternate.

Do I need both HTML and plain text, or can I send only one?

Sending only HTML is allowed but increases spam filter suspicion. Sending only plain text is allowed and fine for transactional or short notification emails. Sending both (multipart/alternative) is best practice for marketing and most transactional sends.

Common problems

Problem: Auto-generated plain text from my ESP is full of HTML markup.

The ESP’s converter is broken or basic. Generate the plain text version manually using this tool, then paste it into the ESP’s plain-text-override field (most ESPs have one, labelled “plain text version” or “alternate content”).

Problem: Plain text version is much shorter than HTML.

Image-heavy HTML campaigns lose a lot when converted because the meaningful content was in the design. Add explanatory text to the HTML version (which also benefits accessibility and image-blocking clients), and the plain-text version becomes more substantial automatically.

Problem: Links disappeared in the conversion.

Either the source HTML had unusual link markup, or the converter stripped them too aggressively. Check that the HTML uses standard <a href="..."> markup; if it does and links still vanish, regenerate or paste the conversion into a different tool.

Problem: Word wrap is breaking in odd places.

Some text isn’t easily word-wrapped (long URLs, code, technical strings). The generator preserves URLs as a unit (no breaking inside an URL); long unbroken strings remain on a single line even if it exceeds 72 chars. This is generally desired behaviour.

Problem: Plain text shows in the inbox preview instead of HTML.

Some clients (older Outlook, certain mobile clients) preview the plain-text alternate. If your subject and first lines look dramatic in HTML but bland in plain text, recipients may see the bland version. Make sure the first paragraph of plain text is still compelling.

Tips

  • Always include a plain-text alternative. Empty or missing plain-text is a deliverability signal that costs nothing to fix.
  • Make plain-text content match HTML content: same words, same order, same calls-to-action. Wide divergence triggers spam suspicion.
  • Test rendering in a plain-text-only client (like Mutt or alpine, or just View Source on a Gmail message and look at the text/plain part). Confirms it reads sensibly.
  • For transactional emails (receipts, password resets), plain text often reads better than HTML. Many users prefer it. Don’t over-engineer the HTML.
  • If you find yourself maintaining elaborate plain-text alternatives, consider whether the HTML version is doing too much. Simpler HTML produces better plain text automatically.

Related tools in this suite

Part of the Email Marketing Suite, this generator handles the multipart/alternative side of deliverability. The Inbox Reachability Checker covers content-side spam signals; plain-text presence is one of them. The Subject Line Tester covers what shows in inbox previews. For the one-click header the Unsubscribe Link Generator is the companion compliance tool.

What this looks like at scale

For a single campaign, the generator is sufficient. For organisations with continuous email programs, plain-text generation should be part of the build pipeline: every HTML template has a plain-text equivalent generated and stored alongside, kept in sync through the campaign-build process. Most enterprise ESPs (Iterable, Braze, Klaviyo) generate plain-text alternatives automatically; verify the output quality is acceptable.

Take it further

If your email program has chronic deliverability issues partly caused by plain-text quality, the structural fix is template-level, building plain-text awareness into the template system rather than per-campaign. Talk through the situation and we can scope what template-level improvements look like.