What is email preview text?

Where the preview snippet comes from

Every major client walks the message body and lifts the first readable text it finds. In an HTML marketing email, that is often exactly what the designer did not intend - "View this email in your browser", a logo's alt text, an unsubscribe notice - which is why the preheader exists: a snippet of text placed first in the HTML and hidden from the rendered view, put there purely to feed the preview line. Client behavior differs in the details (how many characters are shown, how aggressively whitespace tricks are honored, whether the snippet is cached), but the principle is stable: the preview is the first text in the body unless you deliberately supply something else.

How much of it gets seen

There is no single character budget: the visible snippet depends on client, device, screen width and how long the subject is - the subject and preview share one line's worth of attention, and a longer subject leaves less room for preview. The practical planning rule is to front-load: make the first thirty to forty characters carry the point, treat anything beyond ninety as invisible, and never let the opening words be ones you would not put in the subject line itself.

The cold email difference: no preheader, and that is fine

Marketing advice about preview text assumes an HTML template with a hidden preheader block. Cold email that is trying to read like a personal note should not have one: a hidden-text block is a template artifact, and plain-text messages cannot carry one anyway. That collapses the problem into something better: your first sentence is your preview text. It will be judged twice - once as a snippet next to the subject, once as the opening line after the click - so it has to work at both altitudes. A first sentence that only makes sense mid-paragraph wastes the preview; a first sentence engineered only as bait reads hollow the moment the message is open.

Two working consequences. First, never open with throat-clearing ("Hope this finds you well") - in the inbox list that IS your message. Second, put the specific, recipient-relevant fact first: the copywriting principles that make a good opener and a good preview are the same principles, applied once.

Preview text and filtering

The preview line is drawn from body content, so it is scored like body content. Openers built on urgency theater or recognized spam vocabulary hurt in both places at once: they read poorly to the human scanning an inbox and they contribute to how filters classify the message. If you want a mechanical check, the cold email grader scores a draft's opening line along with everything else, and the spam checker flags the vocabulary worth rewriting.

Testing what your preview actually shows

The honest test is empirical: send the draft to your own Gmail and Outlook accounts and look at the inbox list on a laptop and a phone. Four things to check: which words survive truncation, whether the subject and preview read as one thought or repeat each other, whether the first characters would still make sense with the subject covered, and what the message looks like in the client's dark mode. This takes two minutes and replaces most published character-count folklore.

When this page does not apply

• You send designed HTML newsletters. Those carry a hidden preheader by design; this page is about plain-text cold email, where the first sentence is the preview.
• You need an exact character count for one client. No single number holds across clients, devices, density settings and subject lengths; test in the clients your recipients use.
• You want open-rate lift from preview text. Open tracking is not a reliable cold email measure; judge an opener by replies, as covered on cold email metrics.
• Your issue is placement, not the snippet. If mail lands in spam, the preview is not the cause to fix first; start with why cold emails go to spam.

How this page was built and checked

The definitions and the 30-40 / 90 character planning rule are ReplyLead's own, from writing plain-text cold email; the rule is a planning heuristic, not a measured client limit. The simulator truncates with your browser's own layout, not with a quoted character budget. Outlook's message-list views are described from Microsoft's own documentation, linked below; the rest of the client behaviour here comes from our own sending, not from a vendor specification. We did not run a multi-client rendering study for this page. Last checked 24 September 2026.