What is a plain text email?

Plain text, technically

Email messages declare their format. A pure plain-text message contains a single text body; most modern senders actually transmit multipart messages carrying both a plain-text part and an HTML part, and the receiving client picks. "Sending plain text" in practice means one of two things: sending the pure single-part form, or sending HTML so minimal - default font, no images, no layout tables - that it renders indistinguishably from typed text. Both count for the purposes that matter here; what defines the category is the absence of design and of embedded remote content, not the MIME details.

What you give up

Honest accounting first, because plain text is a trade, not magic:

• Design. No brand header, no product shots, no buttons. If the message needs visual persuasion, plain text cannot carry it.
• Open tracking. Opens are measured with an embedded remote image; a message with no images has no open rate. We accept this fully: across our 429,763-send book, open tracking was disabled and no open figure is published or estimated.
• Click instrumentation. Rewritten tracking links are another template artifact. Fewer, plainer links means less mid-funnel data - and cold email's honest metric is the reply anyway.

Why cold email chooses it anyway

It matches the claim the message makes. A cold email works when it reads as a considered note from one professional to another. Real one-to-one mail is plain: nobody sends a colleague a designed template. The format is part of the message's credibility, and a marketing shell contradicts it before the first word is read.

It removes scoring surface. Heavy HTML, remote images, tracking domains and rewritten links each give filtering stacks more to evaluate, and cold mail - sent to recipients with no engagement history - has the least goodwill to spend. Plain text does not make a bad list deliverable; it means the message itself is rarely the problem. Send-side discipline does the rest: warmed mailboxes, low per-mailbox volumes, and lists verified at build time.

It concentrates effort where replies come from. With no design layer, the words are the whole message. That is a feature: the copy - and its first line, which doubles as the preview text - gets the attention a template would otherwise absorb.

The open-rate consequence, stated plainly

Choosing plain text means choosing not to know your open rate. Most of the industry resolves that tension in the other direction and keeps the pixel. We publish the position and its consequence: no opens are reported anywhere in our benchmarks, replies per contacted lead is the headline metric (median 2.12%, pooled 2.58% across 115 campaigns), and every reported number has a denominator attached. An open is a proxy that got less reliable as mail clients started prefetching images; a reply is a human decision. Programmes optimized on proxies drift toward what inflates the proxy.

Writing plain text well

The format has its own craft, mostly subtractive: keep it short, one idea, one light ask; write the first sentence knowing it is also the preview snippet; use line breaks as the only structure; link sparingly and honestly; skip the vocabulary filters already recognize. A signature is name, role, company - a signature that looks like a banner is HTML by another route. The grader applies our eleven checks to any draft, format included.

Plain text email formatting: the rules the standards set

Plain text has fewer rules than HTML, and they are written down. RFC 5322, the message format Google requires of anyone sending to Gmail accounts, says each line "MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF". RFC 2046 says a text/plain body with no charset is read as US-ASCII, so anything beyond it - accents, curly quotes, a non-English name - needs charset=UTF-8 declared. RFC 3676 adds format=flowed, where a line that ends in a space is a soft break the reader's client may re-wrap; its lines SHOULD be 78 characters or shorter, and it suggests wrapping at 72. These limits apply to the lines as sent: RFC 3676 ties the 78-character restriction to the characters "between CRLFs on the wire", and mail software meets it with format=flowed or quoted-printable soft line breaks (RFC 2045, section 6.7, which keeps encoded lines to 76 characters). So do not break paragraphs by hand; on narrow screens that produces what RFC 3676 calls "embarrassing line wrap".

A "plain text" email is sent in one of two common forms, shown below. In the second, the message carries an HTML part as well, and because RFC 2046 puts the preferred format last and tells receiving clients to "pick and display the last format they are capable of displaying", an HTML-capable client usually shows the HTML. That is why an editor's plain-looking draft can still arrive with rewritten links or a tracking pixel.

What a sent plain text email looks like

Here is the example message from the converter below as it travels, form 1 with format=flowed. [SP] marks the trailing space that makes a line flowed (RFC 3676 section 4.1): the reader's client joins it to the next line and re-wraps the paragraph to the screen, while every line as sent stays under 78 characters. Names, addresses and the company are invented; the date and Message-ID are placeholders.

From: Sam Lee <sam@example.com>
To: Dana Park <dana@example.net>
Subject: Second warehouse in Ohio
Date: [date]
Message-ID: <[id]@example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dana,

Saw that Northwind opened a second warehouse in Ohio last month.[SP]
Teams at that stage usually start losing track of carrier quotes.

We built a quote tracker (https://example.com/quotes) for that exact[SP]
moment.

Worth a 15-minute look next week?

Sam
Head of Partnerships, Example Co

Form 2 wraps the same words in a multipart/alternative message, with the HTML part last:

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

--b1
Content-Type: text/plain; charset=UTF-8; format=flowed
(the words above)
--b1
Content-Type: text/html; charset=UTF-8
(the same words with HTML markup)
--b1--

Convert and check a draft

Paste an HTML or text email to see its plain-text version, the links it would write out, any images or tracking pixels it would drop, and how its line lengths compare with RFC 5322's limits.

When this page does not apply

• You send newsletters or product marketing to opted-in lists. HTML earns its place there, as the questions below say; this page is about one-to-one outreach.
• You need open rates. A plain text email has no tracking pixel, so it has no open rate; measure replies per contacted lead instead.
• Your sending tool rewrites the message. Some tools add an HTML part, tracking links or a pixel on their own; check the source of a sent message, not the editor view.
• You write beyond US-ASCII. Declare charset=UTF-8 on the text/plain part; without a charset, US-ASCII is assumed.

How this page was built and checked

The formatting rules are quoted from RFC 5322, RFC 2046, RFC 3676 and RFC 2045 and from Google's sender guidelines, each read on 24 September 2026 and asserted word for word when this page was built. The converter applies the simple rules stated under it in your browser and is not a full MIME encoder. The campaign figures (429,763 emails, a median campaign reply rate of 2.12% per contacted lead across the 81 campaigns with at least 500 contacted leads, automatic replies included) come from ReplyLead's campaign book on the benchmarks page; the side-by-side message is illustrative. ReplyLead runs cold email and LinkedIn outbound.