Skip to content
Sales Pitch
Menu
English

Avoid Spam in Sales: Plain Text vs HTML and the One or Two Links Rule

, 8 min read

Avoid Spam in Sales: Plain Text vs HTML and the One or Two Links Rule

Decorative plain text and HTML email title card

Plain text (text/plain) contains only characters and line breaks, with no styling of any kind. HTML (text/html) contains markup that creates fonts, colors, images, buttons, and clickable links. When you need your message to display correctly for every recipient, the safest practice is to send both formats together using multipart/alternative, letting each email client pick the richest version it can render.

TL;DR:

  • Sending messages as multipart/alternative ensures that recipients see HTML if supported, otherwise they receive a clean plain-text version.
  • Plain text avoids variability in rendering, blocks external images, and is more effective for personalized outreach or transactional messages.
  • Proper conversion and sanitization are essential, including ordering parts correctly and ensuring all links are absolute.
  • HTML is preferable for newsletters, branding, and styled content, but can trigger spam filters if overused or overly tracked.
  • Testing your email in clients that block images helps confirm that your plain-text fallback remains clear and functional.
Usesalespitch
usesalespitch.com
Improve Your Cold Email Strategy
Sales Pitch shares practical insights, templates, scripts, and tools for B2B professionals refining outreach and email deliverability.
Visit Sales Pitch

Table of Contents

Plain Text vs HTML: What Actually Separates Them

The difference starts with how each format is labeled at the protocol level. Every email or web message carries a Content-Type header that tells the receiving system what kind of body it’s looking at, and this labeling is governed by RFC 2045, which defines the Content-Type and charset parameters that indicate how a message body should be interpreted. Get that label wrong and the content can render as garbled text or raw code instead of a readable message.

RFC 2046 is the standard that actually defines the two subtypes. It states that text/plain must contain no formatting commands or directives and should be displayed exactly as written, while text/html is the subtype reserved for markup-based content. Developer guidance from MDN Web Docs confirms the same split in practice: text/plain is the default for simple text files, and text/html is the correct type whenever markup is present.

In practical terms:

  • Plain text shows exactly what was typed, line by line, with no tags, images, or colors.
  • HTML can embed images, apply brand colors, create styled buttons, and arrange content into columns or sections.
  • Plain text relies on the recipient’s own font and display settings, while HTML can override most of that within the limits of the client’s supported CSS.

A styled call-to-action button, a logo header, or a two-column layout are only possible in HTML. A short, personal note that looks like it came from a person rather than a template is where plain text tends to win.

How Clients Render and Convert Each Format

Rendering is where the theoretical difference becomes a visible one. HTML emails depend on the recipient’s email client correctly interpreting embedded CSS, and client support varies widely: some clients block remote images by default, others strip out certain style rules entirely, which means the same HTML email can look different across Gmail, Outlook, and a mobile mail app.

Plain text avoids that variability entirely. There’s no CSS to misinterpret and no images to block, so what you send is what the recipient sees. One behavior worth knowing: some systems automatically convert raw URLs typed into a plain-text message into clickable links, while HTML messages require an explicit anchor tag to create that same clickable behavior, a distinction documented in LiveAgent’s support material on email formatting.

When a message is sent as multipart/alternative, the client renders the richest version it supports and ignores the rest, according to RFC 2046’s multipart guidance. The standard requires the plain-text part to be listed first and the HTML part last, and the receiving client works backward from the richest format it can display.

  • If a client can render HTML, it shows the HTML part and discards the plain-text version.
  • If it can’t (or the recipient has disabled HTML rendering), it falls back to the plain-text part automatically.

How to Convert Between Plain Text and HTML

Converting between formats is a routine task, and getting the order and sanitization right matters more than the specific tool you use.

  1. Start with clean plain text. Write or export your message as plain text first, preserving paragraph breaks and avoiding long unbroken lines.
  2. Strip HTML down to text when needed. Use an HTML-to-text converter or a library in your development stack that removes tags while preserving paragraph structure and whitespace.
  3. Sanitize any HTML you generate. Remove script and iframe tags, inline only the styles you need, and avoid depending on external stylesheets that many clients will ignore.
  4. Assemble the multipart/alternative message with plain text first, HTML last. This order matches the RFC 2046 standard and ensures clients that support HTML render it while others fall back gracefully.
  5. Keep links absolute. Relative URLs can break depending on how a client parses the HTML part, so write every link in full.

Pro Tip: Test your multipart message in at least one client that blocks images by default. If the plain-text fallback still reads clearly on its own, your message is doing its job in both formats.

A quick sanitization checklist before sending: no embedded scripts, no iframes, collapsed whitespace, and every link preserved and absolute in both versions.

When to Use Plain Text, HTML, or Both

The right format depends on what the message needs to accomplish.

  • Plain text tends to perform better for cold outreach and personalized one-to-one messages, since it reads like a note from a person rather than a campaign.
  • HTML is the better choice for newsletters, product announcements, or any message that depends on visual hierarchy, a logo, or a styled button.
  • Transactional messages (receipts, password resets, confirmations) often work fine as plain text, which also tends to land more reliably in the inbox.
  • Sending both formats through multipart/alternative is the safest default when you don’t know how your recipient’s client is configured.

Before choosing, consider the recipient’s likely device, your sending domain’s deliverability history, and whether the message truly needs branding or just needs to be read and understood.

What This Means for Sales Teams Sending Outreach

What This Means for Sales Teams Sending Outreach — overview diagram

For cold outreach specifically, plain-looking, personalized text consistently reads as more credible than a heavily branded HTML template. A message that resembles a personal note, free of logos and tracked buttons, tends to earn a reply rather than a delete. HTML earns its place further down the funnel, in nurture sequences and newsletters where visual branding and consistent CTAs matter more than looking personal.

Formatting choices also tie directly into deliverability. HTML-heavy messages with tracking pixels and multiple links carry more signals that spam filters evaluate, while a clean plain-text message with one or two links tends to stay out of trouble. We cover these signals in more depth in our guide to cold email deliverability and spam triggers, and our collection of cold email templates gives you starting points built around plain-text best practices.

— Samuel

FAQ

Is HTML the Same as Plain Text?

No. Plain text (text/plain) contains only characters and line breaks with no formatting, while HTML (text/html) contains markup that produces styling, images, and links, a distinction defined in RFC 2046.

How Do I Know if My Email Is HTML or Plain Text?

Check the message’s Content-Type header, which labels the body as either text/plain or text/html per RFC 2045. Visually, plain text shows no colors, fonts, or embedded images, while HTML displays styled layouts and clickable buttons.

What’s the Difference Between Text and HTML?

Text is unformatted content displayed exactly as written, while HTML uses tags to create visual structure like headings, colors, and embedded images, as described in developer guidance from MDN. HTML also supports clickable buttons and layout columns that plain text cannot produce.

Should I Use HTML or Plain Text Emails for a Mail Merge?

Plain text often works better for personalized mail merge outreach because it reads like an individual message rather than a template. Sending both formats via multipart/alternative gives recipients the richest version their client supports while keeping a readable fallback for everyone else.

Sources

More from the blog