HTML Email vs Plain Text: Which Gets Better Inbox Placement?

The plain-text-vs-HTML debate refuses to die. Cold-email gurus on LinkedIn still post screenshots claiming plain text doubled their reply rate. Marketing-automation vendors counter with stats showing HTML emails out-perform on engagement. Both are partially right and both are missing the same point: every modern email should be sent as multipart/alternative, with a properly-rendered text part and a properly-rendered HTML part. That is the spec, and it is what filters expect.

TL;DR

HTML-only emails are mildly suspicious. Plain-text-only emails look unusual from anything other than a personal mailbox. Multipart/alternative — both parts present, both parts saying the same thing — is what every legitimate sender does and what filters are tuned for. Send both.

What multipart/alternative actually is

Defined in RFC 2046, multipart/alternative is a MIME structure that ships two (or more) versions of the same message body. The receiving client picks the version it can render best. Mail clients with HTML support show the HTML; mail clients without it (rare today, but certain accessibility tools and old terminal clients still rely on it) show the text.

Content-Type: multipart/alternative; boundary="b1"

--b1
Content-Type: text/plain; charset=utf-8

Hi Sarah, here is the proposal we discussed...

--b1
Content-Type: text/html; charset=utf-8

<html><body><p>Hi Sarah, here is the proposal we discussed...</p></body></html>
--b1--

This is what every well-behaved mailer produces — Gmail's web composer, Apple Mail, Outlook, Postmark, SendGrid, transactional pipelines, every B2B SaaS notification you've ever received. It is the baseline expectation.

Why HTML-only signals automation

A message arriving as text/html with no plain-text alternative was, historically, a hallmark of bulk-marketing software that didn't bother to generate a text version. It is still treated that way by most filter heuristics. SpamAssassin rule MIME_HTML_ONLY assigns a small but persistent penalty.

Beyond rules, sending HTML-only also breaks accessibility for screen readers using text-mode mail clients, breaks rendering on the rare client without HTML support, and damages display in accessibility-focused mailboxes (VoiceOver routed through certain configurations). The cost of including a text part is zero. There is no reason to omit it.

Why plain-text-only is also suspicious now

The 2018-era cold-email advice was: "send pure plain text, no HTML, you'll look like a personal email and inbox better." This worked briefly. Filters caught up.

A pure plain-text message from a domain that otherwise sends professional, multipart messages stands out in the senders's own pattern. A pure plain-text message from a brand-new domain with no other sending history reads as a scrappy mass-mail attempt. Gmail's ML doesn't penalise plain-text directly, but the absence of an HTML part is a feature in the engagement model — and the model has learned that bulk cold senders disproportionately use plain-text-only.

From real testing in 2025, plain-text-only cold outreach averaged ~3% lower inbox rates than the same content sent as multipart from the same domain. Not catastrophic — but the myth that plain-text inboxes better is exactly backwards.

How to write the plain-text part well

The text part is not throwaway. Filters score the text part independently. Things that go wrong:

Auto-generated text from HTML. Most ESPs strip HTML poorly — leave dangling brackets, lose link context, dump tracking-pixel URLs into readable text. Always review or author manually.
Mismatched content. If the text part says one thing and the HTML part says another, that's a phishing signal. Filters do compare. Keep them semantically equivalent.
URL formatting. Plain text can't do anchor text. Don't leave long tracker URLs visible — use shorter, clean URLs in the text part where possible.
Empty text part. Some ESPs ship multipart with a single-character text body when the user only authored HTML. That's as bad as omitting the text part.

HTML rules that still apply

Modern HTML email rendering is a constrained world. Gmail, Yahoo and Outlook each strip different things. The HTML part should:

Use inline styles. Most CSS in <head> gets stripped.
Use table-based layout for compatibility — modern flexbox/grid unevenly supported across clients.
Avoid JavaScript entirely. Stripped by every client; presence of <script> tags raises spam scores.
Avoid <form> and <iframe>. Stripped or warned about.
Keep external CSS minimal — most clients won't fetch it.
Render visibly without images — many clients block images by default until the user opts in.

The hidden HTML check that catches everyone

Filters check whether the HTML part renders to roughly the same word count as the text part. If your HTML is 2,000 visible words and your text part is "See attached", that's a strong manipulative-pattern flag. Same content, both formats. No shortcuts.

Length and weight ratios

Total message size matters less than people think — modern filters happily process emails up to ~100KB without penalty. What does matter:

Text/HTML ratio. The HTML part should be at most ~3-4x the byte size of the text part for a typical message. Heavily styled HTML pushing 50:1 ratio reads as bulk-template.
Text/image ratio inside HTML. Visible text should be present even when images are blocked. See our separate piece on image-to-text ratio.
Total size. Above ~100KB, Gmail clips the message. Above ~10MB, most providers reject. Keep below 100KB for cold outreach.

Real-world examples

Three sending patterns and how they're received:

Sales rep using Gmail compose. Gmail produces multipart/alternative automatically. Text part is auto-derived, generally clean. HTML part is minimal styling. This is the gold-standard signal because it's genuinely human.
Marketing automation (HubSpot, Mailchimp, etc.).Multipart with heavy HTML, complex tracking pixels, large unsubscribe footer. Filters know these patterns and route them to Promotions. Not spam, but not Primary either.
Cold-email tool (Instantly, Smartlead, etc.).Multipart with minimal HTML mimicking a personal email, minimal tracking. The good ones produce output indistinguishable from human Gmail compose at the MIME level. The cheap ones ship HTML-only or empty-text-part — and bury accounts.

Practical recommendations

Always send multipart/alternative. Both parts populated. Both parts saying the same thing.
Keep HTML simple. Inline styles. Single-column. No background images, no JS, no forms.
Author the text version manually for cold outreach. The 5 minutes of effort is worth measurable inbox lift.
Audit what your sending tool produces. Send a message to yourself and view source. Confirm both parts exist and look clean.
Stop chasing the "plain text inboxes better" myth. It hasn't been true since at least 2020.

Frequently asked questions

My ESP only lets me write HTML — should I switch?

No. Most modern ESPs auto-generate the text part from the HTML. Audit the text part it produces (send to yourself, view raw source) to make sure it's readable. If it's garbage, switch to an ESP that lets you author both parts.

Does plain-text-only ever inbox better?

In rare cases — extremely high-deliverability domains targeting Gmail users only, where the recipient is conditioned to expect plain personal emails from your address. Even then, the gain is marginal and you lose accessibility. Multipart wins overall.

What about Markdown — does that count as plain text?

Markdown sent as text/plain is just text with asterisks. Filters score it as plain text. If your tool converts Markdown to HTML for the HTML part and ships the raw Markdown as text, that's perfectly fine — both parts are valid.

Do I need a different HTML for mobile?

No — use responsive HTML (single-column, max-width: 600px). Separate mobile HTML went out around 2018 with the rise of CSS media queries.

HTML email vs plain text: which gets better inbox placement?