HTML Email to Plain Text

Why Every HTML Email Must Have a Plain-Text Alternative

Email is sent as a MIME multipart message. The most common format is multipart/alternative, which packages both the HTML version and the plain-text version in a single message. The recipient's email client chooses which to display based on its capabilities and user settings.

Sending an HTML-only email creates three problems:

• Spam filter risk: major spam filters (SpamAssassin, Google's filters, Microsoft Defender) penalise emails that lack a plain-text part. The absence of a text alternative is a weak signal that the sender did not follow email best practices — and spam is often HTML-only.
• Delivery failures in certain environments: some corporate email gateways strip HTML for security. Some command-line email clients display only the text part. Some users explicitly configure their clients to prefer plain text.
• Accessibility failures: screen readers work best with structured plain text. A carefully crafted HTML email may be difficult to navigate in an HTML rendering mode; the text alternative provides a clean, linear reading path.

What Makes a Good Plain-Text Email Alternative

A plain-text email alternative is not just a stripped version of the HTML. It should be readable on its own:

• Clear paragraph breaks: each paragraph should be separated by a blank line, not compressed into a single block.
• Readable list items: bullet points should appear as - Item text or • Item text lines rather than items concatenated into a sentence.
• Explicit URLs: hyperlinks should include the full URL in parentheses after the anchor text — e.g., Visit our site (https://example.com) — since plain text cannot render clickable links.
• No HTML entities: characters like &, <, copyright symbols, and em-dashes must be decoded to their actual Unicode characters.
• No tracking pixel artefacts: 1×1 tracking images produce no visible text but may contribute empty lines or alt text if not handled correctly.
• Appropriate line length: many email systems recommend lines of 72–80 characters in the plain-text part for maximum client compatibility.

How to Use the Flowfiles Tool for Email Conversion

The Flowfiles HTML tag stripper is well-suited for generating plain-text email alternatives:

• Paste your full HTML email template into the input area.
• Enable "Preserve line breaks" so paragraphs appear on separate lines.
• Enable "List items as bullets" to convert <li> elements to readable bullet lines.
• Enable "Collapse blank lines" to prevent excessive whitespace from heavily nested table-based email layouts.
• Review the output and manually add full URLs for any critical call-to-action links whose href was lost during stripping.
• Copy the result and paste it into your ESP's plain-text field (Mailchimp, Klaviyo, Campaign Monitor, etc.).

Table-Based Email HTML: Special Considerations

Legacy HTML email templates use nested <table> layouts for visual alignment — a practice inherited from 2000s email client limitations. When stripped to plain text, a four-column product grid becomes four sequential paragraphs, which may look odd. The solution is to reorder the content manually in the text alternative to match the logical reading flow rather than the visual grid.

Modern email templates built on CSS Flexbox or Grid layouts are easier to convert: content is already in source order, matching the visual top-to-bottom reading flow.

ESPs That Require a Plain-Text Alternative

Most email service providers either require or strongly recommend a plain-text alternative:

• Mailchimp: automatically generates a plain-text version, but the auto-generated output is often low quality. Manual refinement is recommended.
• Klaviyo: includes a plain-text tab in the email editor. Custom content must be entered manually.
• Postmark and SparkPost: used for transactional email; both accept separate TextBody and HtmlBody parameters in the API.
• AWS SES: supports both HTML and text bodies in the SendEmail API call; both are recommended for transactional messages.