A plain text email is an email whose message body contains only readable characters and line breaks, without HTML tags, CSS styling, embedded images, buttons, tables, or custom fonts. It can be sent on its own as text/plain, or included with an HTML version in a multipart/alternative message so each recipient’s email client can display the version it supports best.

What is a plain text email?

Plain text email is the simplest form of email content. Instead of rendering a visual design, it presents words, punctuation, spaces, and line breaks in the recipient’s default email-client font. There are no styled headings, colored call-to-action buttons, tracking pixels, image banners, or complex layouts.

A text-only message might look like this:

Subject: Your order #4821 has shipped

Hi Maya,

Good news: your order #4821 has shipped.

Track it here:
https://example.com/orders/4821/track

Estimated delivery: Tuesday, May 12.

Thanks,
The Example Store team

That simplicity does not make it obsolete. Plain text remains a core email format, both for direct person-to-person communication and for application-generated messages such as password resets, receipts, incident alerts, security notices, and delivery updates.

For marketing and lifecycle email, the usual best practice is not necessarily to choose between HTML or plain text. It is to send both representations of the same message in one properly structured MIME email. The recipient’s mail client can then use the HTML version when it can render it and use the plain text version when it cannot, when the recipient prefers text, or when an intermediary strips rich content.

The Internet Message Format defines the basic structure of email messages, including headers and bodies. MIME extends that model so a single message can carry different content types, including text/plain, text/html, attachments, and alternative renderings of the same message. (datatracker.ietf.org)

Plain text email vs. HTML email

The difference is about representation, not message purpose. A plain text email and an HTML email can communicate the same update, offer, receipt, or alert. They differ in what the email client has to interpret.

What plain text can do

A plain text email can include:

  • Paragraphs and line breaks
  • Simple headings made with capitalization or separators
  • Numbered and bulleted lists using characters such as -, *, or 1.
  • Full URLs
  • Email addresses and phone numbers
  • Basic personalization, such as a recipient’s first name
  • Unicode characters when the message declares and uses an appropriate character set, commonly UTF-8

It cannot natively create a branded button, responsive columns, an image gallery, a colored background, or an interactive card. Some mail apps may automatically link URLs or format phone numbers for dialing, but that is a client convenience—not formatting embedded by the plain text message itself.

What HTML can do

HTML email supports visual layout and presentation. A sender can use HTML to provide a logo, a product image, a button, styled typography, tables, background colors, and responsive email structure. But email HTML is a constrained environment: mail clients differ in what they support, may remove scripts and unsafe markup, and may render CSS differently.

That is why the plain text counterpart should not be treated as an accidental byproduct of the HTML version. It is its own reader-facing format with its own usability requirements.

Plain text is not Markdown

Markdown is a lightweight writing syntax that some applications convert into formatted output. Plain text email may contain Markdown-like characters, but email clients generally do not interpret **bold**, [label](https://example.com), or # Heading as rich formatting.

If you send this:

[View your invoice](https://example.com/invoices/4821)

many recipients will see those exact brackets and parentheses. A clearer plain text equivalent is:

View your invoice:
https://example.com/invoices/4821

Write the text version for a person reading literal text, not for an HTML renderer that never arrives.

Why plain text email matters for deliverability

A plain text email is not a standalone deliverability cure. Simply adding a text/plain part will not compensate for poor consent practices, high complaint rates, weak authentication, an unhealthy list, misleading content, or a damaged sending reputation.

Mailbox providers evaluate many signals beyond message body format. For example, Gmail’s sender requirements emphasize authentication, valid DNS configuration, encrypted transport, low spam rates, and unsubscribe requirements for qualifying bulk senders. Gmail’s Postmaster Tools also reports separate areas such as authentication, message format, delivery errors, and user-reported spam. (support.google.com)

Still, a well-written plain text part can support dependable delivery and a better recipient experience in several important ways.

It provides a readable fallback

Not every recipient views email in the same way. Some people disable HTML, use privacy-focused readers, rely on text-based or accessibility-oriented tools, view mail through security gateways, or receive messages in environments where rich content is altered.

A usable text/plain version ensures the essential message survives. The recipient should still be able to understand what happened, what action is needed, whether there is a deadline, and where to go next.

For a password reset, that means the plain text version needs the reset link and expiry information. For a receipt, it needs the order identifier, items or summary, total, and support path. For a campaign, it needs the offer, key conditions, destination URL, and an opt-out route where applicable.

It reduces mismatch risk

A weak fallback can create confusion even when the HTML version renders perfectly for most people. Common examples include a text part that says only “This email requires HTML,” contains placeholder copy, omits the main link, or includes an unedited dump of navigation links from the HTML template.

That mismatch can hurt trust. A recipient who sees a sparse or broken text message may reasonably question whether it is legitimate, especially if the HTML version uses a recognizable brand but the text version does not identify the sender clearly.

It helps preserve the message through transformations

Email frequently passes through forwarding services, security scanners, archiving systems, mobile applications, and mailbox-provider processing. A properly constructed multipart message gives receiving software a legitimate alternate representation to use rather than forcing it to extract meaning from HTML.

The multipart/alternative subtype exists for alternate representations of the same information. RFC 2046 specifies that the alternatives are ordered by increasing faithfulness, meaning the preferred rendering is generally the last supported part. In a typical text-and-HTML email, text/plain comes first and text/html follows. (rfc-editor.org)

It supports clearer operational messages

Transactional email is often read under time pressure. A simple alert that says “Your API key was revoked” or “Your invoice payment failed” may be more useful than a large visual design when the recipient is on a slow connection, using a screen reader, or scanning email on a small screen.

The goal is not to make every message visually plain. It is to ensure that the underlying communication remains direct and complete when visual presentation is unavailable.

How plain text email works in MIME

MIME, short for Multipurpose Internet Mail Extensions, lets an email message declare what kind of content it carries. A text-only message normally has a content type such as:

Content-Type: text/plain; charset=UTF-8

The text/plain media type tells the mail client that the body is plain text. The charset=UTF-8 parameter tells it how to decode characters such as accented names, non-Latin scripts, curly quotation marks, and emoji.

A plain text-only message

A minimal raw message might be structured like this:

From: Example Store <orders@example.com>
To: Maya Chen <maya@example.net>
Subject: Your order #4821 has shipped
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi Maya,

Your order #4821 has shipped.
Track it: https://example.com/orders/4821/track

Thanks,
Example Store

In production, a sending platform usually generates or validates some headers, handles SMTP transport, and manages encoding details for you. But understanding the raw structure is useful when debugging malformed emails, inspecting source, or configuring a lower-level mail library.

A multipart plain text and HTML message

When you send a visual HTML email with a readable fallback, use multipart/alternative. The message has a parent content type and boundaries that separate its parts:

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="alt-boundary-4821"

--alt-boundary-4821
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi Maya,

Your order #4821 has shipped.
Track it: https://example.com/orders/4821/track

--alt-boundary-4821
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!doctype html>
<html>
  <body>
    <p>Hi Maya,</p>
    <p>Your order <strong>#4821</strong> has shipped.</p>
    <p><a href="https://example.com/orders/4821/track">Track your order</a></p>
  </body>
</html>

--alt-boundary-4821--

The message body should use CRLF line endings in the wire format, even though examples are often displayed with ordinary line breaks. Each boundary starts with --, and the final closing boundary adds another -- at the end.

The two parts should represent the same core message. They do not need to be character-for-character identical. HTML can use a button while plain text uses a labeled URL; HTML can display a product image while text describes the product. But the recipient must not lose material information merely because the plain text version was selected.

Correct ordering matters

Place the plain text part before the HTML part in multipart/alternative. RFC 2046 describes alternatives in ascending order of faithfulness, with the last supported type usually chosen for display. Putting HTML last follows the conventional and interoperable pattern. (rfc-editor.org)

Do not use multipart/mixed as though it were automatically an alternative container. multipart/mixed is for independent parts, such as an email body plus attachments. When an email has both alternatives and attachments, the common structure is a multipart/mixed outer container with a nested multipart/alternative body section and attachment parts beside it.

multipart/mixed
├── multipart/alternative
│   ├── text/plain
│   └── text/html
└── application/pdf attachment

This distinction affects how clients interpret the parts. An attachment is not an alternate rendering of the body, and an HTML body is not an attachment to the plain text body.

Encoding considerations

Plain text is still subject to transport and encoding rules. UTF-8 is a practical default for modern email content, but the actual content transfer encoding should be appropriate for the message and mail infrastructure.

For mostly ASCII copy with occasional non-ASCII characters, quoted-printable is often useful because it keeps much of the content human-readable while encoding special bytes safely. Base64 is generally more appropriate for binary data and can make text cumbersome to inspect or troubleshoot. Your email library or provider should handle this automatically when it accepts structured text and HTML inputs.

Do not manually encode text unless you are building raw MIME messages and understand the consequences. Incorrect soft line breaks, a missing charset, or a broken boundary can turn a simple fallback into garbled content.

Plain text email is not a deliverability metric

Unlike bounce rate, complaint rate, open rate, or click rate, plain text email is not a rate and has no universal formula. You do not calculate a “plain text email score” by dividing one sending total by another.

Instead, assess it as an implementation and quality property:

  1. Presence: Does the HTML email include a non-empty text/plain alternative?
  2. Parity: Does the text version communicate the same material information and primary action?
  3. Readability: Can someone understand it without images, styling, or automatic link formatting?
  4. Technical validity: Are the MIME type, character set, boundaries, and encodings correct?
  5. Operational usability: Do links, variables, legal details, and unsubscribe instructions still work in text form?

You can track coverage internally if you want an engineering quality metric. For example:

Plain text coverage =
(messages with a meaningful text/plain part ÷ HTML messages sent) × 100

If a system sent 48,000 HTML-capable emails in a month and 46,800 had a meaningful plain text fallback, its internal coverage would be:

(46,800 ÷ 48,000) × 100 = 97.5%

That 97.5% figure is a useful internal QA measurement, not an industry-standard deliverability metric. It tells you where template or integration gaps exist; it does not tell you whether a mailbox provider will place the mail in the inbox.

Common plain text email problems

Most plain text failures are not caused by the format itself. They result from an incomplete generation process, a broken template, or an assumption that the text part is unimportant.

Empty or meaningless fallback copy

The most obvious problem is a text/plain part that contains no meaningful content. Examples include:

Please view this message in an HTML-compatible email viewer.

or:

[Company logo]
[Hero image]
[Button]

Neither version tells the recipient what happened or what to do. Replace placeholders with a complete text-first message that includes the important information and a direct URL.

Copying raw HTML into the text part

If recipients see <table>, <div>, &nbsp;, long CSS fragments, or tracking markup, the sender likely placed HTML source in a text field or mislabeled the MIME content type.

This is both a technical and editorial failure. Test the raw message and the rendered output in more than one client before deploying a template change.

Missing links or unlabeled URLs

HTML buttons often hide the destination URL behind copy such as “Manage subscription.” In plain text, write a descriptive label followed by the complete URL.

Manage your subscription:
https://example.com/preferences?token=abc123

Avoid a paragraph made entirely of unlabelled URLs. If a recipient is scanning a text-only inbox, labels explain what each destination does before they open it.

Broken personalization tokens

A text and HTML template may use different rendering paths. That can leave plain text messages with unresolved variables such as {{first_name}}, an empty order ID, or a missing account URL.

Test text and HTML output using the same representative data sets. Include names with punctuation and non-ASCII characters, long product names, missing optional fields, multiple currencies, and URL parameters. A fallback is only reliable if it handles real data, not just the happy-path preview record.

Unreadable line length

Very long lines create a poor reading experience in narrow interfaces and can obscure URLs or code values. Use natural line breaks between ideas, list items, and calls to action. Do not hard-wrap every line at an arbitrary short width if that breaks URLs or makes copy difficult to edit.

For a human-readable transactional message, a practical pattern is short paragraphs, blank lines between sections, and a single purpose per line where appropriate. For example, put a one-time code on its own line so it is easy to find and copy.

Excessive visual noise

HTML templates often include navigation, social links, many campaign modules, legal copy, and image-only dividers. A literal conversion can create an overwhelming text email with thirty links before the primary action.

The plain version should preserve meaning, not every decorative element. Keep the core message, main destination, critical terms, support contact, preference or unsubscribe route when required, and essential legal information. Remove ornamental repetition.

Depending on images for meaning

If the only statement of an offer, expiration date, or security instruction appears in an image, both the HTML and text versions are weak. Important information should appear as selectable text in the HTML version and as normal copy in the plain text version.

This reduces ambiguity for recipients who block images and makes the message more resilient to client differences.

How to write a useful plain text fallback

The best plain text email is concise, complete, and deliberately edited. Start from the recipient’s question: “What is this, why am I receiving it, and what should I do next?”

Use a text-first information hierarchy

A strong structure usually contains:

  1. A clear sender or product identifier
  2. The event, request, or offer
  3. The recipient-specific detail that makes it relevant
  4. One primary action with a full URL
  5. Supporting details, terms, or timing
  6. A support route
  7. Preference or unsubscribe information for subscription email

For example, an account security notice could read:

Example Cloud security alert

Hi Jordan,

A new API key was created for your workspace, Northstar Labs.

Created: May 12, 2026 at 14:32 UTC
Key name: production-deploy

If you created this key, no action is needed.

If you did not create it, review your API keys immediately:
https://app.example.com/settings/api-keys

Need help? Contact support@example.com.

The HTML version may add a warning color and a button, but the plain text version still delivers every operationally important fact.

Make links self-explanatory

Use descriptive text before every important URL. A bare link may be technically functional but unclear, particularly if it includes a long path or signed token.

Good:

Reset your password:
https://example.com/reset?token=...

Less useful:

https://example.com/reset?token=...

If a long link is unavoidable, put it on its own line. Never insert hard line breaks into a URL unless the underlying system is designed to reassemble it safely.

Keep the primary action singular

A promotional HTML design may show several modules and buttons. The plain version should lead with the most important action, then list secondary choices only if they genuinely matter.

This is not merely a formatting choice. A focused text fallback helps recipients who use keyboard navigation, assistive technology, compact mobile views, or email-to-ticket workflows identify the intended next step quickly.

Preserve required subscription controls

For promotional and subscription messages, include an unsubscribe or preference-management URL in the text part as well as in the HTML part. The plain version should not become a loophole that omits controls available in the styled version.

Gmail’s subscription guidance distinguishes subscription messages from transactional messages and states that qualifying senders should correctly implement one-click unsubscribe and process unsubscribe requests within the stated timeframe. The exact obligations that apply depend on message type, recipient, jurisdiction, and sending volume, but the practical principle is simple: do not make recipients rely on HTML to manage communication preferences. (support.google.com)

Use authentic, direct language

Plain text can feel more personal because it strips away visual polish. That is useful only when the language matches the sender’s relationship with the recipient.

Avoid fake reply chains, misleading urgency, ambiguous sender names, or copy designed to disguise a bulk campaign as a one-to-one message. Trust is an email performance asset. Clear identification and honest context are more durable than formatting tricks.

Generating plain text from HTML: what automation gets wrong

Many email systems can generate text automatically from HTML. This is convenient, but automated conversion is not the same as editorial quality control.

A converter might correctly turn a button into a URL while still producing duplicated navigation, image alt text in awkward positions, empty table spacing, repeated product names, or tracking links that are too long to read. It may also omit meaning that exists only in CSS, images, or visual proximity.

Use automatic generation as a draft

Automatic conversion can be a reasonable baseline for low-risk messages, especially when templates are simple and copy is already structured semantically. But review the output before treating it as final.

Build a template workflow where the text version is either authored separately or generated and then edited. This is particularly important for:

  • Security alerts and account notifications
  • Password resets and verification links
  • Payment failures and invoices
  • Legal notices
  • High-value product announcements
  • Complex newsletters with many modules
  • Messages containing dynamic product or account data

Maintain content parity intentionally

Create a content checklist for every template. Ask whether both formats include the same:

  • Subject context
  • Recipient name or account reference
  • Key status or event
  • Date, deadline, or expiry
  • Primary action
  • Essential terms or price information
  • Help contact
  • Unsubscribe or preferences path where applicable

The visual version may contain more decoration; the text version should never contain less decision-critical information.

Test the final rendered data

Template previews can hide production problems. Send seed messages with real-looking data to a test inbox, then inspect both the rendered email and its raw source.

For developer-generated mail, use a provider and workflow that lets you separately set and validate text and HTML bodies rather than relying on opaque conversion. The email API reference and setup guides should be the starting point for implementing and testing multipart messages through your sending integration.

Plain text email examples by use case

The appropriate style depends on why the recipient is receiving the message.

Password reset

Reset your Example App password

We received a request to reset the password for your account.

Choose a new password:
https://example.com/reset-password?token=...

This link expires in 30 minutes.

If you did not request a password reset, you can safely ignore this email.

This version identifies the event, supplies the action, states the expiration, and offers reassurance. It does not need design elements to be useful.

Shipping update

Your order has shipped

Hi Priya,

Order #4821 is on the way.

Carrier: Example Express
Tracking number: EX123456789
Track your package:
https://example.com/track/EX123456789

Estimated delivery: May 14.

Keep operational identifiers easy to copy. Do not hide the tracking number inside a sentence or image.

Product campaign

Spring plan upgrade offer

Hi Leo,

Upgrade to the Pro plan by May 31 and receive 20% off your first three months.

See plan details and upgrade:
https://example.com/pricing?offer=spring

Offer terms: Available to eligible active Starter customers. Discount applies to subscription fees only.

Manage email preferences:
https://example.com/preferences
Unsubscribe:
https://example.com/unsubscribe

The text version can be shorter than the landing-page-like HTML campaign, but it still needs the offer, action, deadline, material condition, and subscription controls.

Testing and monitoring plain text email quality

Testing should cover both format correctness and recipient experience. A message can be syntactically valid yet still be confusing, incomplete, or operationally broken.

Inspect the MIME source

In a received test email, inspect the original or raw message source. Confirm that:

  • The parent container is multipart/alternative when sending text and HTML alternatives.
  • A text/plain part exists before the text/html part.
  • Each part declares an appropriate charset.
  • Boundaries open and close correctly.
  • The text part contains readable copy, not HTML markup.
  • Dynamic values render correctly in both parts.
  • URLs are complete and point to the intended destination.

If the message has attachments, confirm the alternative body is nested correctly inside a mixed container rather than flattened into an ambiguous structure.

Test representative mail environments

At minimum, send seed messages to different major mailbox providers and view them on both desktop and mobile where possible. Also test with images disabled, in a mail client that displays plain text prominently, and with a screen reader or accessibility review process if your organization supports one.

The point is not to seek a single universal rendering. Email has no universal rendering. The point is to verify that every supported representation remains understandable.

Watch engagement and complaints in context

Do not attribute changes in inbox placement, conversions, or complaints solely to adding a plain text part. Email performance is influenced by audience quality, consent, authentication, sender reputation, timing, frequency, relevance, subject lines, and the message itself.

Use provider data to identify broad delivery issues. Gmail’s Postmaster Tools, for example, exposes information related to spam rate, reputation, authentication, and delivery errors for personal Gmail recipients. (support.google.com)

Then use template-level QA to determine whether recipients who receive the text version encounter broken copy, missing calls to action, or inconsistent unsubscribe controls. These are distinct disciplines: deliverability monitoring tells you whether delivery is healthy at a system level, while text-part testing tells you whether the message is usable in a fallback context.

Plain text email best-practice checklist

Before sending an HTML-capable message, review the text alternative against this checklist:

  • Does it clearly identify the sender and purpose?
  • Can a recipient understand the message without images or formatting?
  • Does it include the same essential facts as the HTML version?
  • Is the primary action labeled and followed by a complete URL?
  • Are time-sensitive details, prices, codes, and account identifiers preserved?
  • Are personalization tokens resolved correctly?
  • Are paragraphs and lists easy to scan on a narrow screen?
  • Does the text avoid raw HTML, duplicated navigation, and decorative clutter?
  • Does it include support information where useful?
  • Does it include a usable preference or unsubscribe route for subscription email?
  • Is text/plain placed before text/html in a valid multipart/alternative structure?
  • Has the final output been tested with realistic recipient data?

A strong plain text fallback is not a compliance checkbox or an afterthought. It is a second, resilient representation of the same communication.

The practical takeaway

Plain text email is the text-only representation of an email message. It can stand alone for concise transactional communication, but it is most commonly valuable as the text/plain fallback paired with an HTML version in a multipart/alternative MIME message.

It does not magically improve sender reputation or inbox placement. Deliverability depends on much more than body format, including authentication, list quality, consent, recipient engagement, and complaint rates. But a complete and technically sound text version improves compatibility, preserves critical meaning when HTML cannot be used, and gives recipients a clearer, more trustworthy experience.

Treat the plain text body as a real message. Write it for humans, keep it aligned with the HTML content, expose essential links and details, and test it as carefully as the version with the logo and buttons.

FAQ

Is a plain text email better for deliverability than HTML email?

Not inherently. A plain text email alone does not guarantee inbox placement. Authentication, recipient consent, spam complaints, list hygiene, sending behavior, and sender reputation have much larger effects on deliverability. A useful plain text part is still valuable because it improves compatibility and gives HTML email a readable fallback.

Should every HTML email include a plain text version?

In most production sending systems, yes. Include a meaningful text/plain alternative whenever you send an HTML body. It gives recipients and mail clients another usable representation of the same message and protects against incomplete rendering or HTML stripping.

What MIME type should a plain text email use?

Use Content-Type: text/plain, normally with a character set such as charset=UTF-8. When sending both text and HTML versions, place them inside a multipart/alternative message, with text/plain first and text/html second. (rfc-editor.org)

Can a plain text email contain links?

Yes. Include the full URL as visible text, ideally after a descriptive label. Some email clients will automatically make URLs clickable, but the message should remain understandable even if the client displays the URL as ordinary text.

Can I automatically convert HTML email into plain text?

You can, but treat automatic conversion as a starting point rather than a final result. Review it for missing information, duplicate links, raw markup, awkward spacing, image-dependent meaning, and broken personalization before you send it to recipients.