Email format — plain text versus HTML — is one of the most frequently debated and most frequently oversimplified deliverability questions. The conventional wisdom holds that "plain text has better deliverability." The more accurate statement: plain text email has specific deliverability advantages in specific contexts, while HTML email has legitimate reasons to exist and can achieve excellent deliverability when implemented correctly. The format choice is not one-size-fits-all — it is context-dependent, and making the right choice requires understanding how spam filters, AI inbox systems, and human engagement patterns differ in their responses to the two formats.
How Spam Filters Treat Plain Text vs HTML Differently
Modern spam filters evaluate email format as one signal among many, not as a primary classification trigger. The format-related signals that filters evaluate:
Plain text signals: Plain text email (Content-Type: text/plain) has no images, no styling, no links requiring URL analysis, and no HTML code complexity. From a filter's perspective, plain text is the simplest possible email — it resembles personal, one-to-one communication. The filter must rely primarily on sender reputation, authentication, and content language analysis. Plain text email is associated with personal communication and low-volume B2B outreach in filter training data — which generally produces more favourable default classification.
HTML signals: HTML email (Content-Type: text/html) introduces image loading from external servers, CSS styling, link destinations that require URL reputation checking, and HTML code complexity that can hide content or introduce parsing errors. Spam extensively uses HTML to embed malicious links, hide trigger words, and structure content in ways that evade text analysis. Filters have extensive training data on HTML spam patterns and are calibrated to evaluate HTML email more carefully than plain text. This does not mean HTML email is treated as inherently suspicious — legitimate HTML email from established senders with good reputation passes without issue — but it means more filter evaluation surface area.
SpamAssassin HTML-specific rules: SpamAssassin (used in many enterprise email gateways) has explicit rules that score HTML email characteristics: HTML_MESSAGE (email has HTML content, small baseline score), MIME_HTML_ONLY (email has HTML but no plain text alternative, moderate negative score), HTML_IMAGE_ONLY_x (image-dominant HTML email, negative scores scaling with image dominance), and HTML_OBFUSCATE_x (suspicious CSS or hidden content, high negative scores). A plain text email has none of these rules triggered by definition.
AI Inbox Systems and Email Format Signals in 2026
Gmail's Gemini AI Inbox, Apple Intelligence, and Microsoft Copilot all process email content to generate summaries, assess relevance, and apply inbox prioritisation. Email format affects how easily and accurately these AI systems can process the email content:
Plain text + AI: Perfect compatibility. Gemini AI can read and summarise plain text email without any parsing challenges. The email's content is immediately and completely accessible to the AI system — no image-embedded text to ignore, no complex HTML structure to parse, no CSS-hidden content to filter. Gemini generates an accurate summary from the full email text. The AI inbox summary is maximally informative, and the AI's relevance assessment is based on the complete content.
HTML + AI: Good compatibility when HTML is well-structured; problematic when it is not. Well-coded HTML email (valid structure, text in HTML text nodes rather than images, reasonable text-to-code ratio) is parsed successfully by AI systems. Poorly coded HTML (image-only content, text hidden in images, invalid nesting) produces incomplete or inaccurate AI summaries because the AI cannot read content that exists only as pixels in an image file. Gemini AI's evaluation of email quality — which influences inbox visibility — is based on the textual content it can parse. HTML email with significant image-embedded text is effectively invisible to Gemini's content evaluation.
Plain Text Deliverability Advantages
Plain text email has four specific deliverability advantages over HTML email:
1. No HTML parsing errors: Plain text has no HTML to be invalid, no nesting to be incorrect, no attributes to be missing. The 74% HTML issue rate documented by unspam.email's 2025 report — invalid nesting, missing alt attributes, excessive code — applies only to HTML email. Plain text email by definition has no HTML issues.
2. No image-loading signals: HTML email loading external images creates a network signal: the receiving server (or proxy, in the MPP case) makes outbound HTTP requests to image servers. Bulk email image requests at scale are a distinguishing feature of HTML email. Plain text generates no image-loading network activity.
3. No URL reputation complexity: Plain text emails can contain URLs, but their URL structure is simpler than HTML email. HTML email wraps every link in tracking redirect URLs, uses image src URLs, and may use multiple link destination domains. Each unique URL in an HTML email requires a reputation check by the spam filter's URL analysis. Plain text with fewer, simpler URLs creates less URL-analysis surface area.
4. Personal email resemblance: Spam filters are trained to distinguish mass commercial email from personal communication. Visual formatting (headers, footers, branded colours, images) is the strongest single signal of commercial mass email. Plain text resembles personal communication because personal email is almost universally plain text. This resemblance signal contributes to more favourable classification in contexts where one-to-one personal communication is the expected norm — specifically B2B professional communication.
When HTML Is Necessary and Worth the Trade-off
HTML email is the appropriate format for specific use cases where visual presentation creates value that plain text cannot provide:
E-commerce transactional email: Order confirmations, shipping notifications, and cart abandonment email all contain product images, order summaries with tabular layouts, and brand-reinforcing visual design. Plain text order confirmation is technically functional but creates a poor customer experience when the customer is trying to reference specific products, prices, and shipping information. The visual clarity of HTML transactional email justifies the format choice — and transactional email achieves excellent deliverability regardless of HTML format because its engagement signals (near-100% open rates from expected recipients) outweigh any format scoring disadvantage.
Consumer newsletters with visual identity: Publications with established visual brands — newsletter-as-media brands, content businesses, consumer lifestyle publications — use HTML to maintain the visual consistency that is part of the brand identity. For these programmes, the visual brand is part of the value proposition, and plain text would fundamentally degrade the product. The deliverability trade-off is manageable with proper HTML coding standards.
Product-driven transactional notifications: SaaS product usage reports, analytics summaries, data visualisation email — these naturally require HTML tables, charts, or formatted data that plain text cannot represent clearly. The HTML complexity is justified by the content value.
Multipart MIME: Sending Both Simultaneously
The production best practice for most commercial email programmes is multipart/alternative MIME — sending both a plain text version and an HTML version in the same email, with the receiving email client or server choosing which version to display. This approach provides HTML visual presentation for clients that render HTML well, while providing a plain text fallback for clients that prefer or require it, and providing spam filters with readable text content even when the HTML version is complex.
# Multipart MIME structure: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="BOUNDARY_STRING" --BOUNDARY_STRING Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Plain text version of the email content here. This is what spam filters and AI systems read most easily. All key messages from the HTML version should appear here. CTA Link: https://brand.com/offer --BOUNDARY_STRING Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html> <html> <body> [Full HTML version with images, styling, tracking links] </body> </html> --BOUNDARY_STRING--
The critical best practice for multipart MIME: the plain text version must be a genuine, readable representation of the email's content — not just auto-stripped HTML tags, not just "Please view the HTML version," and not a sparse skeleton of the HTML content. A meaningful plain text version ensures that spam filters evaluating the plain text part see the actual email content, AI systems summarising the plain text part get the full message, and recipients who prefer plain text get a complete, readable email. Many ESPs auto-generate the plain text version by stripping HTML tags — the result is often unreadable. Write the plain text version manually or review the auto-generated version carefully before sending.
B2B and Cold Email: The Case for Plain Text
For B2B professional email — sales development outreach, account executive follow-ups, business development email — plain text is the clear format winner on both deliverability and engagement grounds. Data across multiple studies shows plain text achieving 23% higher open rates in B2B contexts than equivalent HTML email, with higher reply rates for programmes that actively solicit replies.
The B2B preference dynamics: business professionals reading email in a professional context are evaluating whether the email merits their attention and a response. HTML formatting — branded headers, footers with social media icons, promotional design elements — signals "marketing email" immediately, even when the content is a personal outreach from an individual. Plain text signals "email from a person" — the same visual pattern as communication from a colleague, a client, or a business contact. This signal-level categorisation affects both the human's engagement decision and Gmail Gemini's AI classification of the email as personal vs bulk commercial.
For cold email specifically, plain text is the unambiguous choice: (1) No MIME_HTML_ONLY SpamAssassin penalty (plain text has no HTML at all, not just no plain text alternative). (2) No image tracking pixel to trigger MPP-style pre-fetching that inflates open analytics. (3) Personal email resemblance that passes the Copilot "is this personal or bulk commercial" classification more favourably. (4) Forced focus on content quality — plain text email cannot hide behind visual design; the copy either works or it doesn't.
Newsletter and Marketing Email Format Strategy
For consumer-facing newsletters and marketing email, the format choice is less clear-cut than for B2B cold email. The deliverability difference between well-coded HTML and plain text is smaller for newsletters than for cold email — because newsletter audiences are opted-in with positive engagement histories that outweigh format scoring differences. The engagement and brand presentation considerations dominate the format decision for newsletters, not deliverability per se.
A middle path that some newsletter publishers have found effective in the 2026 AI-inbox context: near-plain-text HTML — HTML email that looks and feels like plain text (no images except a small logo, minimal or no CSS styling, text-heavy content) but retains the technical HTML structure needed for tracking, click attribution, and the List-Unsubscribe header. Near-plain-text HTML gets the personal email resemblance signal of plain text while retaining the analytical capabilities (click tracking, link attribution) of HTML. Gmail Gemini can parse it easily, Copilot classifies it as more personal than visual marketing email, and the deliverability outcomes closely resemble plain text.
Testing Email Format Impact on Your Specific Programme
The format decision for any specific programme should be validated with an A/B test rather than assumed from general principles. The test framework: (1) Take an active campaign with sufficient volume for statistical significance (at least 2,000 recipients per variant). (2) Send 50% of recipients the current HTML version. (3) Send 50% a plain text version of the same content. (4) Measure click-to-delivered rate (CTD) — not open rate, which MPP inflates asymmetrically for HTML email — and revenue-per-delivered for e-commerce programmes. (5) Run inbox placement testing with GlockApps for both variants to identify format-driven inbox placement differences. (6) The variant with higher CTD and better inbox placement is the correct format choice for this programme's audience and content type.
One important caveat on format testing: the inbox placement difference between well-coded HTML and plain text for established, engaged permission-based programmes is often small — 1-3 percentage points. For programmes with poor HTML code quality (falling in the 74% non-compliant category), the improvement from fixing HTML quality may be larger than the improvement from switching to plain text. Audit HTML quality first (see the HTML Structure guide on this site), and consider format switching only after HTML quality has been maximised and inbox placement is still below the target level. Format is the second-order variable; code quality is the first-order variable within the HTML format category.