Plain Text vs HTML Email: What the Statistics Show

Short answer: in the published A/B tests I could find, the plain-looking version converted better. Litmus saw 60% of converting existing customers come from the plain-text-styled email, and 49% for non-customers (Litmus, 2020). But almost every one of those tests compared a heavy HTML template against a lightly designed HTML email, not against a true text/plain message. That distinction changes the answer, and no listicle on page one mentions it.

Here is what I found when I went looking for the actual numbers, and where the evidence runs out.

What the published tests actually found

I went looking for large-sample studies that split results by email format. There are fewer than you would expect from how confidently this topic gets written about.

Litmus, 2020

Litmus split two webinar audiences 50/50 and measured sign-ups. Among existing customers, 60% of the people who converted had received the plain-text-styled email. Among non-customers, 49% did — which is a coin flip, not a win. Their own write-up flags a problem with the first round: the two versions differed in messaging as well as format, so the test measured both at once. They reran it, and the customer segment came in at 63% for the plain, personal version (Litmus, 2020).

Read that carefully. The headline number people quote — plain text wins — comes from one vendor's webinar invitations, one segment, with an acknowledged confound in the first round. It is real evidence. It is not a law.

HubSpot

HubSpot analysed what they describe as over half a billion marketing emails and reported that the more HTML-rich an email was, the lower its open rate, and that even a single image reduced click rate (HubSpot). Their published charts do not carry legible numbers, so I am reporting the direction of the finding and not a percentage. If you see a specific figure attributed to this study, ask where it came from.

They also found a gap between what people say and what they do: surveyed marketers prefer HTML, and their sends perform better plain.

What the email community says it prefers

Litmus polled its own audience the same year. 68.3% on Twitter and 85% on LinkedIn voted for HTML (Litmus, 2020). Stated preference among email professionals runs hard against the measured behaviour of their recipients. Both things are in the data.

Where the evidence does not exist

I could not find a major benchmark report — Mailchimp, Campaign Monitor, Brevo, Salesforce — that segments its open and click averages by message format. They segment by industry, region, list size and send time. Not format. So when a post tells you plain text emails get some specific percentage more opens and cites a benchmark report, that number is not in the report.

I have no first-party send data of my own to add here, so I am not adding any.

The comparison table

The middle column is what most "plain text" advice is actually describing, and it is what Litmus actually tested.

Deliverability: the myth and the mechanism

The folklore says plain text lands in the inbox and HTML lands in Promotions. The real mechanism is narrower.

What is not in dispute is the multipart/alternative structure: send both a text/plain and a text/html part inside one message and let the receiving client pick. That is what the MIME standard defines it for, and most ESPs will generate the plain-text part for you. The related claim — that HTML-only messages attract more filtering — is repeated everywhere, but I could not find a controlled public study behind it. Treat it as a cheap default, not a measured effect.

What is not established is that plain text buys you inbox placement on its own. Gmail, Outlook and Apple deliver enormous volumes of legitimate HTML mail every day. Domain reputation, authentication, list hygiene and complaint rate move placement. Format is a rounding error next to those. If you are switching to plain text hoping to fix a deliverability problem, you are treating a symptom.

One practical corollary: never ship the auto-generated plain-text part without reading it. A converter that turns your template into a wall of [image] and bare tracking URLs produces a text part that is worse than none.

Rendering: what the client market share implies

Litmus tracks email client share from over a billion opens per month. In July 2026 the split was Apple 62.26%, Gmail 27.03%, Outlook 5.83% (Litmus).

Two things follow. First, your rendering QA surface is smaller than the check-it-in-40-clients advice implies — three engines cover well over 90% of opens. Second, Gmail's clipping behaviour matters more than its 27% share suggests, because clipping truncates the message silently rather than degrading it visibly. Mailchimp documents the threshold at 102KB of message size, past which Gmail hides the rest behind a "View entire message" link (Mailchimp). Google does not publish this number itself, which is worth knowing before you build a process around it.

Clipping is the most concrete argument against heavy HTML, because it hits your unsubscribe link and your tracking pixel — both of which usually sit at the bottom.

Check your HTML weight before you send

Stdlib Python. It builds a correct multipart/alternative message and tells you where the HTML part sits against the 102KB line.

"""Build a multipart/alternative email and check the HTML part against
Gmail's ~102KB clipping threshold (Mailchimp). Python 3 stdlib only."""
from email.message import EmailMessage

GMAIL_CLIP_BYTES = 102 * 1024

def build(subject, sender, to, text_body, html_body):
    msg = EmailMessage()
    msg["Subject"], msg["From"], msg["To"] = subject, sender, to
    msg.set_content(text_body)                      # text/plain part
    msg.add_alternative(html_body, subtype="html")  # text/html part
    return msg

def report(msg):
    parts = {p.get_content_type(): len(p.get_payload(decode=True) or b"")
             for p in msg.walk() if not p.is_multipart()}
    html = parts.get("text/html", 0)
    return {
        "structure": msg.get_content_type(),
        "parts": parts,
        "html_bytes": html,
        "pct_of_gmail_limit": round(100 * html / GMAIL_CLIP_BYTES, 1),
        "will_gmail_clip": html > GMAIL_CLIP_BYTES,
    }

if __name__ == "__main__":
    text = "Hi Sam,\n\nOne question about your onboarding flow.\n\n- Santosh\n"
    html = ("<html><body><p>Hi Sam,</p><p>One question about your onboarding"
            " flow.</p><p>- Santosh</p></body></html>")

    lean = report(build("Quick question", "s@example.com", "sam@example.com", text, html))
    print(lean)
    assert lean["structure"] == "multipart/alternative"
    assert set(lean["parts"]) == {"text/plain", "text/html"}
    assert lean["will_gmail_clip"] is False

    # the same email wrapped in a heavy template
    bloated = html.replace("<body>", "<body>" + "<table style='%s'></table>"
                           % ("padding:0;margin:0;border:0;" * 40) * 300)
    heavy = report(build("Quick question", "s@example.com", "sam@example.com", text, bloated))
    print(heavy)
    assert heavy["will_gmail_clip"] is True
    print("OK")

Running it here: the lean version is 104 bytes of HTML, 0.1% of the limit. The bloated one is 343,304 bytes — 328.7% — and gets clipped. Point report() at your real template export and you will know before you send, not after.

Accessibility cuts against the folklore

Plain text is often called the accessible option. That is half right, and the half it gets wrong matters.

Plain text is guaranteed readable: no contrast failures, no unlabelled images, no dark-mode inversion bugs. But it has no semantic structure at all. A screen reader user cannot jump between headings in a text/plain email, because there are no headings — only line breaks that happen to look like one. Well-built HTML with real heading tags, alt text and descriptive link text is more navigable than a wall of line breaks. The accessibility argument therefore runs opposite to the intuition: the fix for an inaccessible HTML email is better markup, not less of it.

So the accessible choice is not "no HTML". It is HTML somebody bothered to mark up properly, with a readable plain-text alternative alongside it. Same principle I apply to web pages in writing for skimmers: structure is what makes content navigable, and removing structure removes navigation.

Tracking: what true plain text actually costs you

A real text/plain message cannot carry a tracking pixel. No pixel, no open rate. You also lose click tracking unless you rewrite links into visible redirect URLs, which look like exactly what they are and undercut the personal effect you were buying.

This matters less than it used to. Apple's Mail Privacy Protection downloads remote content in the background when the message arrives, whether or not the recipient ever reads it (Apple). Set that against Apple's 62.26% share of tracked opens and your open rate is already measuring something other than opens for most of your list.

If your open rate is largely fictional, losing open tracking is a smaller cost than it sounds. Measure replies, clicks and downstream conversions instead — the same argument I make about picking metrics that actually move.

Which format for which send

• —One-to-one and one-to-few outreach where you want a reply. True plain text, from a personal address. If it looks like a campaign, it gets answered like a campaign.
• —Nurture sequences and text-first newsletters. Plain-styled HTML in a multipart message. You keep tracking and a working unsubscribe link, and it still reads like a person wrote it.
• —Product launches, sales, event promos, digests with many links. Full HTML. You need the visual hierarchy. Keep the source under 102KB.
• —Transactional mail. HTML with a genuinely readable plain-text part. Someone will read the text version — in a watch notification, a terminal client, a screen reader.

The honest position is that format is a second-order variable. Segmentation, offer and timing move results more than either column of the table above. I make that case at length in why email is not dead for B2B.

FAQ

Do plain text emails get better open rates than HTML?

HubSpot's analysis of over half a billion emails found that more HTML-rich messages had lower open rates (HubSpot). Treat any open-rate comparison cautiously, though: Apple Mail Privacy Protection preloads content on arrival, and Apple accounted for 62.26% of tracked opens in July 2026 (Litmus).

Is plain text or HTML better for deliverability?

Neither, on its own. Send multipart/alternative with both parts — that is what the MIME standard provides for, and it costs nothing. Reputation, authentication and complaint rate decide inbox placement; format does not rescue a bad sender.

What is the difference between plain text and plain-styled HTML email?

True plain text is a text/plain message with no markup, no images and no tracking. Plain-styled HTML looks similar but is still HTML — it can carry bold text, links, a tracking pixel and an unsubscribe footer. Most published "plain text wins" tests, Litmus's included, tested the second one.

When should I use HTML email instead of plain text?

When the message is visual or structural: a product launch, a sale, an event promo, a digest with many links. Also whenever you need reliable click attribution or a compliant unsubscribe footer.

Not sure which format your list actually responds to? Run one honest A/B test on your own audience before importing anyone else's conclusion, including mine. See my services or get in touch.