Email Preheader Text: What It Is and How to Write One (With Examples)

The email preheader (also called preview text) is the short snippet of text shown beside or below the subject line in a subscriber’s inbox, before they open the email. Without a deliberately set preheader, most email clients pull the first readable HTML text they find in your message — often a “View in browser” link, an image alt attribute, or a stray navigation label. That wasted line of inbox real estate is the most common missed optimization in email.

Think of the subject line and preheader as a two-line pitch: the subject hooks attention; the preheader closes the case for opening. Together they determine whether a subscriber reads or skips.

---

Why the Default Behavior Is a Problem

When an email has no explicit preheader, Litmus notes that “your preview text is generated from the first HTML text in your email, which includes the ALT for images such as logos or banners.” That means a subscriber might see:

• “View this email in your browser” — the classic wasted opener
• “[Banner image]” — a blank alt tag or literal bracket notation
• A fragment of transactional boilerplate from a header row

Setting a preheader explicitly takes two minutes and prevents this entirely. It also gives you a second chance to influence the open decision without changing your subject line.

---

How Much Preview Text Email Clients Actually Show

There is no single reliable character limit across clients and devices. Litmus recommends keeping preview text under 90 characters as a practical default, noting that “subscribers can see anywhere from 5 lines of preview text (about 278 characters) to 0 lines of preview text” depending on client settings. Client-specific display ranges vary considerably:

Email Client	Approximate Preview Characters
Gmail (desktop)	90-119 characters
Gmail (mobile)	40-90 characters
Apple Mail (Mac)	up to ~140 characters
Apple Mail (iPhone)	70-90 characters
Outlook (desktop/web)	35-55 characters

These figures come from community testing data and shift over time as clients update their rendering. Treat them as planning guides, not guarantees. The practical safe range for a preheader that reads coherently across all common clients is 40-90 characters — front-load the most important information so truncation never cuts the meaning.

One more wrinkle: Apple Intelligence (introduced in iOS 18.1 and macOS Sequoia 15.1) now generates its own AI-written summary in place of the preheader for some Apple Mail users. Your preheader still matters everywhere else, and the summary generated by Apple Intelligence draws on your email body — so well-written content helps either way.

---

Writing a Preheader That Works: Marketer’s Playbook

A preheader earns its place when it adds information the subject line left out. A preheader that repeats the subject wastes the slot. Here are the principles:

Complement, don’t repeat. If the subject is “Your free trial ends tomorrow,” the preheader should answer the natural follow-up: “Upgrade now and keep everything you’ve built.” Not: “Your free trial expires tomorrow — act fast.”

Front-load the value. Because display length varies across clients, your core message needs to fit in the first 40-50 characters. Anything after that is a bonus on clients that show more.

One idea only. Stuffing multiple benefits into 90 characters produces incoherent preview text. Pick the single most compelling detail and state it clearly.

Skip the filler. Phrases like “This email contains” or “You’re receiving this because” burn characters on content with zero persuasive value. They also read as spam signals.

Pair it with the subject before sending. Read the subject and preheader together as if you were a subscriber. Do they form a coherent two-line pitch? If the preheader could work for any email you send, it’s too generic.

For a broader look at how subject line and preheader work together as an open-rate lever, see our guide to writing email subject lines.

Before/After Examples

Scenario	Weak Preheader	Strong Preheader	What Changed
SaaS activation email	“Welcome to the platform”	“Set up your first workflow in 3 minutes”	Added a specific, timed action
Weekly newsletter	“Here’s what’s new this week”	“5 deployment patterns SREs are actually using”	Replaced generic summary with a concrete hook
Abandoned cart (ecommerce)	“You left something behind”	“Still in stock — your cart expires at midnight”	Added urgency and scarcity
Product update	“Exciting new features are here!”	“Bulk export, dark mode, and a new API endpoint”	Named the actual features
Re-engagement	“We miss you!”	“Here’s what changed while you were away”	Switched from sentimentality to value
Transactional receipt	“Your order has been placed”	“Arrives Thursday — track your package”	Turned a confirmation into useful next step

---

Implementing the Hidden Preheader in HTML

This is the part most tutorials gloss over. A preheader set through your ESP’s UI is fine for simple sends, but if you control the HTML template — which most developers and growth engineers do — you implement the preheader as a visually hidden element at the very top of the <body>.

The Basic Hidden Span

Place this immediately after the opening <body> tag, before any wrapper tables or divs:

<div style="display:none; max-height:0; overflow:hidden; mso-hide:all;">
  Your preheader text goes here.
</div>

The display:none hides the text from the rendered email view. max-height:0; overflow:hidden provides a fallback for clients that handle display:none inconsistently. mso-hide:all suppresses it in older Outlook versions.

The Spacer Entity Trick

The problem with a short preheader: if your text is 60 characters but the client allocates 120 characters of preview space, it fills the remainder with whatever comes next in the HTML — often a logo alt attribute or a navigation item.

The fix is to follow your preheader div with a second hidden div packed with invisible spacer characters. Litmus describes the technique: “all you need to do is add a chain of zero-width non-joiners (͏ and ‌) and non-breaking spaces ( ) after the preview text you want displayed.”

For broader compatibility across Yahoo Mail and iOS 16+, also include   (figure space) and ­ (soft hyphen):

<!-- Preheader text: hidden from rendered email, visible in inbox preview -->
<div style="display:none; max-height:0; overflow:hidden; mso-hide:all;">
  Your preheader text goes here.
</div>

<!-- Spacer: prevents clients from pulling body content into the preview slot -->
<div style="display:none; max-height:0; overflow:hidden; mso-hide:all;" aria-hidden="true">
  &#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;
</div>

Notice the aria-hidden="true" on the spacer div. Screen readers using display:none already suppress the content from the accessibility tree, but some clients handle this inconsistently. Adding aria-hidden="true" to the spacer div is a belt-and-suspenders measure: community testing has shown that VoiceOver can read out sequences of zero-width characters as noise when display:none is not fully honoured. The preheader text div itself — which contains meaningful content — does not need aria-hidden.

Accessibility note

The preheader text you write is meaningful copy and should stay accessible. Keep it natural language. Avoid stuffing keywords or filler phrases into the hidden preheader purely for preview optimization — a screen reader user who encounters the hidden text should not be confused by it. The spacer entities, however, carry no meaning and should be hidden from screen readers via aria-hidden.

Client behaviour varies: test before sending

This technique works across Gmail, Apple Mail, and most major clients, but email client rendering changes frequently. Litmus’s hack article notes this should be treated as “a progressive enhancement rather than a hack that works everywhere.” Send a test to yourself across the clients your audience uses before deploying to your full list. Tools like Litmus or Email on Acid let you render across 90+ clients in minutes.

For how this fits into a complete HTML email template, see building a responsive email template or sending HTML email.

---

Personalizing the Preheader with Dynamic Values

A static preheader works for broadcast sends. For triggered emails — onboarding sequences, receipts, re-engagement flows — you can use merge tags to make the preheader dynamic. A transactional receipt might show:

Your order #{{order_id}} ships on {{estimated_delivery_date}}

A personalized onboarding sequence:

{{first_name}}, here's your next step in getting set up

The same character-limit and front-loading rules apply. Dynamic values can expand: if {{first_name}} is “Alexander-Christoph,” the rendered preheader will be considerably longer than if it’s “Li.” Build your template with realistic worst-case values in mind.

---

Preheader as Part of Your Email Design System

The preheader isn’t just a copywriting detail — it’s a design element that should be part of every email template you ship. Codifying how your templates handle the hidden preheader span (and where authors set the preview text value) prevents the “View in browser” fallback from showing up in production sends.

If your team uses a visual template builder, check that the tool exposes a dedicated preview text field and inserts the hidden span correctly in the generated HTML. This is one of the areas where the email design best practices for systematic template management pay off: a reviewed template catches a missing preheader implementation before it goes out to 50,000 subscribers.

If you’re looking for a templating and automation platform where preheader/preview text is a first-class field across both visual and code-based templates, Coldletter is built for exactly this.

---

Frequently Asked Questions