What percentage of emails are viewed in HTML vs plain text?
Matthew Whittaker
Co-founder & CTO, Suped
Published 15 Jul 2025
Updated 26 May 2026
11 min read
Summarize with
For most modern email programs, the practical answer is that almost all opened emails are viewed as HTML. A safe working estimate for broad consumer and marketing audiences is 98% to 99.9% HTML, with true plain text viewing usually under 1%. In B2B lists that include government, defense, healthcare, finance, legal, or cybersecurity recipients, I would plan for a higher plain text share, often 1% to 6%, and sometimes 5% to 10% or more in locked-down environments.
That range has an important caveat: no sender has a clean global measurement of plain text opens. True plain text does not load tracking pixels, and most mail clients automatically choose the richest MIME part they can display. So the best number is not a universal benchmark. It is a planning estimate backed by your own click and rendering tests.
The direct answer: assume HTML is the normal viewing path. Keep a useful plain text part because some recipients, security controls, accessibility workflows, and old or restricted clients still need it. Do not expect open tracking to prove how often it was viewed.
The distinction matters because many people say "plain text email" when they mean a simple HTML email with mostly text. A true plain text email has no images, no styling, no buttons, and no hidden tracking pixel. Email on Acid gives a useful plain text definition that separates actual text/plain email from plain-looking HTML.
The practical percentage range
If I had to set a planning number before seeing any audience data, I would use this model: consumer retail and newsletter traffic is effectively all HTML, general B2B has a small plain text tail, and highly controlled sectors need a real plain text plan. The exact percentage depends less on the sender and more on the recipient environment.
Planning ranges for plain text viewing
Use these as planning assumptions, then validate against your own sends.
Typical consumer list
Under 1%
Retail, media, ecommerce, SaaS newsletters, and app lifecycle messages.
Mixed B2B list
1-6%
Corporate inboxes, procurement, sales, support, and operations contacts.
Locked-down audience
5-10%+
Security-sensitive organizations where HTML rendering is limited or stripped.
Those ranges are deliberately conservative. The plain text share can be close to zero for a normal promotional list. It can also be high enough to affect revenue, support deflection, or compliance messaging if your audience works behind strict security controls.
|
|
|
|---|---|---|
B2C | Under 1% | Normal clients render HTML. |
SaaS | Under 1-3% | Mostly HTML, some corporate controls. |
Enterprise | 1-6% | Security tools can strip formatting. |
Government | 5-10%+ | HTML can be limited by policy. |
Approximate plain text viewing ranges by audience type.
The old claim that plain text is always "way under 1%" is reasonable for many lists, but it is too blunt for every sender. The 1% to 6% range is believable for some industries because security controls and internal mail policies can force a text-only experience.
Why the number is hard to measure
Most published HTML vs plain text data measures performance of a send format, not the percentage of recipients who saw the text/plain MIME part. That is a different question. A plain-looking HTML email can still have links, pixels, tracking parameters, layout markup, and client-rendered HTML.
Diagram showing why plain text email opens are hard to measure.
- Tracking gap: Open tracking depends on an image request. True plain text has no image, so a normal open pixel cannot fire.
- Client choice: Mail clients usually choose the richest part they can render, which normally means text/html.
- User access: Many normal clients do not expose an obvious button to view the alternative text part.
- Privacy noise: Image proxying, privacy prefetching, and corporate gateways make open data less precise.
This is why I treat plain text opens as an inferred metric. You can count clicks from unique text URLs, support replies that reference text-only copy, or controlled seed-account observations. You cannot reliably count every person who viewed the text part.
What senders want
- Open split: A clean percentage of opens viewed as HTML versus text.
- Client split: A breakdown by app, device, and recipient setting.
- Global benchmark: One number that applies across industries.
What can be measured
- Click split: Unique HTML and text links show which part drove a click.
- Seed results: Test inboxes show which part specific environments render.
- Domain pattern: Recipient domains can reveal high-security clusters.
What normal mail clients display
When an email uses multipart/alternative, the message contains both a text/plain part and a text/html part. The client is expected to display the best version it supports. In practice, almost every mainstream consumer and business mail client supports HTML and displays the HTML part.
Simplified multipart email structuretext
Content-Type: multipart/alternative; boundary="abc" --abc Content-Type: text/plain; charset="UTF-8" This is the plain text version. Visit https://example.com/plain --abc Content-Type: text/html; charset="UTF-8" <p>This is the HTML version.</p> <a href="https://example.com/html">Visit the page</a> --abc--
The text part is still worth doing well. It is the fallback for environments where HTML is unavailable, disabled, transformed, or intentionally avoided. It also keeps your message more complete for archiving, accessibility tooling, and unusual clients. The practical question is not whether you should include it. The practical question is how much effort it deserves.
For normal campaigns, I would not spend the same design time on plain text that I spend on HTML. I would spend enough time to make the text version readable, complete, and safe to act on. If you are deciding whether to send multipart alternative email, the answer is usually yes.
Do not use a lazy plain text fallback that says "view this email in a browser" and nothing else. That leaves security-restricted recipients with no usable message, and it makes your brand look careless in the exact environments where trust matters most.
When plain text usage gets higher
Plain text usage rises when a recipient environment has a reason to distrust active or richly formatted content. This is most common in organizations where accidental clicks, hidden content, image loading, link rewriting, and external calls are treated as operational risks.
- Security policy: Some organizations strip HTML, block remote images, rewrite links, or render simplified text.
- High-risk roles: Security, legal, finance, procurement, and executive teams often have stricter mail controls.
- Old systems: Ticketing systems, archives, terminal clients, and some device previews can prefer text.
- Manual preference: A small group of users deliberately configures clients to avoid HTML where possible.
If you send into these environments, the text part is not just a fallback. It is part of the message. This is also where authentication and reputation matter more. A recipient security stack that strips or downgrades HTML is also likely to care about SPF, DKIM, DMARC, domain reputation, and link behavior.
Suped's product helps with the infrastructure side of that equation. The domain health check can validate authentication basics, while DMARC monitoring helps you catch authentication failures and unauthorized sources before they distort deliverability conclusions.
Email tester sample report showing total score, email preview, issue summary, and per-section results
How to measure your own audience
The best answer for your list comes from a controlled test. I would not run a test that changes the whole message strategy on day one. Start with a normal multipart message, keep the offer and core copy consistent, and add measurement that separates HTML-driven clicks from plain text clicks.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Use Suped's email tester to send a real message and inspect the MIME structure, authentication, content, and rendering issues before you use the campaign as a measurement source. If the message is malformed, your HTML versus text conclusion can be wrong before the send even starts.
- Build both parts: Create a complete HTML version and a complete plain text version with the same offer and deadline.
- Separate links: Use distinct tracking parameters for text links and HTML links, then compare clicks instead of opens.
- Segment domains: Compare consumer domains, corporate domains, government domains, and high-security accounts.
- Control copy: Do not make the text version shorter, weaker, or less clear than the HTML version.
- Review replies: Look for replies that quote plain text wording or mention missing images, stripped links, or display issues.
The cleanest observable metric is not "plain text open rate". It is "plain text click share among people who clicked". If 0.4% of clicks came through text-only links, that does not prove only 0.4% viewed the text part. It proves at least that many people acted from that part.
Flowchart for testing HTML and plain text email usage.
How much effort to put into plain text
For a normal marketing sender, the right answer is not to abandon HTML. HTML is what nearly every recipient will see, and it gives you layout, links, images, accessibility structure, and analytics. The right answer is to keep the HTML simple enough to render well, while making the text part good enough that it can stand on its own.
HTML version
- Primary path: Design for the format most recipients will see.
- Simple markup: Avoid fragile layouts, excessive images, and hidden copy.
- Accessible copy: Use real text, clear links, alt text, and readable contrast.
Plain text version
- Fallback path: Write it as a complete message, not a placeholder.
- Readable layout: Use short lines, clear sections, and visible URLs.
- Action clarity: Make the CTA understandable without buttons or styling.
A simple HTML email often performs better than a heavy design because it feels more personal and is easier for clients to render. HubSpot's HTML testing data found that simpler emails beat more HTML-rich variants in its tests. I would treat that as a reason to simplify design, not as proof that every brand should send only true plain text.
A good rule is to spend most production effort on the HTML version, then spend enough time on the text part to make it accurate, complete, and easy to click or copy. If your audience includes restricted mail systems, spend more time on text copy and test it directly. The broader question of when plain text needed depends on the audience, the message type, and the risk of the recipient missing essential content.
Deliverability implications
HTML versus plain text is usually not the main deliverability driver. Authentication, sender reputation, complaint rates, content quality, list hygiene, and recipient engagement carry more weight. Still, message format can affect filtering and user behavior when the HTML is broken, image-heavy, misleading, or hard to parse.
- Malformed HTML: Broken markup can make a message look suspicious or render poorly. More on malformed HTML is useful when debugging odd results.
- Image-heavy email: Recipients and filters struggle when the actual message is hidden inside images.
- Bad fallback: A missing or useless text part does not usually block delivery by itself, but it hurts edge cases.
- Weak auth: If SPF, DKIM, or DMARC fails, format testing becomes harder to interpret.
This is where Suped fits the workflow without pretending that DMARC tells you who viewed plain text. Suped helps validate the sending foundation, detect authentication issues, monitor DMARC policy, and surface deliverability signals. Then your HTML versus text test has a cleaner baseline.
Best practice: send multipart/alternative, keep the HTML simple, make the text part complete, test the MIME output, and use click evidence rather than open pixels to estimate plain text usage.
Stripo's benchmark roundup also notes that published figures can be incomplete or hard to compare. That matches how I would use the available data: useful for direction, weak for exact percentage claims.
Views from the trenches
Best practices
Use separate text and HTML click URLs so the rare plain text path is measurable.
Keep the plain text part complete enough for security-restricted readers to act.
Segment results by recipient domain type before changing global production effort.
Common pitfalls
Do not compare HTML opens with plain text opens because text has no tracking pixel.
Do not assume a simple-looking email is true plain text if it still uses HTML links.
Do not ignore government or security-heavy audiences when planning text fallbacks.
Expert tips
Treat true plain text viewing as a floor measured by clicks, not a full audience count.
Test MIME output before launch so broken alternatives do not skew the observed data.
Use plain text only for locked-down audiences when HTML creates more risk than value.
Marketer from Email Geeks says true plain text usage varies heavily by audience, and B2B lists with strict security controls can sit well above normal consumer averages.
2024-11-27 - Email Geeks
Marketer from Email Geeks says mainstream mail clients support HTML and usually display the HTML part rather than letting the user choose the text part.
2024-11-27 - Email Geeks
The answer to use in planning
Use 98% to 99.9% HTML as the default expectation for normal modern email audiences. Use under 1% true plain text for most B2C and general newsletter lists. Use 1% to 6% for mixed B2B if your list includes large enterprises or regulated industries. Use 5% to 10% or more as a risk range when you send into government, defense, cybersecurity, or other environments that intentionally restrict HTML.
Then validate your own audience with click-level evidence. Keep HTML as the primary experience, keep text/plain useful, and do not let an unmeasurable plain text open rate drive the whole design strategy.
