Email preheader text — the preview snippet that appears in the inbox list view after the subject line — is one of the highest-impact, lowest-complexity email optimisation opportunities available. A well-crafted preheader that extends the subject line's message and creates genuine curiosity increases open rates 5-15% compared to emails with no preheader or auto-generated preheader from first body text. The technical implementation of preheader also affects deliverability — the still-common practice of using white-on-white hidden text for preheader introduces content scoring signals that some corporate spam filters penalise as a spam pattern. This guide covers both the technical implementation and the commercial optimisation of email preheader.
What Preheader Text Is and How Clients Use It
The preheader is the text snippet shown in the inbox list view immediately after the subject line. In most email clients it appears in grey or lighter text below the sender name and subject. The preheader gives the recipient a second line of context before deciding whether to open the email — it is effectively the subject line's second sentence. Email clients that display preheader include Gmail (web and mobile), Apple Mail, Outlook on iOS and Android, Yahoo Mail, and most modern mobile email apps. Outlook on Windows does not display a preheader in the desktop client — it shows only the subject line, making preheader optimisation most valuable for mobile and webmail audiences.
The preheader content is determined by the email client through one of two mechanisms: if the sender explicitly includes a preheader element in the HTML (the recommended approach), the client displays that text; if no explicit preheader is included, the client extracts the first readable text from the email body — which is often navigation links, legal disclaimers, or "View in browser" text rather than meaningful preview content. Auto-extracted preheaders consistently underperform explicit preheaders on open rates because the auto-extracted content is typically not preview-optimised.
Technical Implementation: The Correct HTML Method
The correct technical implementation for email preheader uses a span element placed immediately after the opening body tag with CSS that hides it visually without triggering spam filter penalties:
<body>
<!-- Preheader text: visible to email clients for preview, hidden in email body -->
<span class="preheader" style="
display: none; /* Hidden from visual rendering */
max-height: 0; /* Zero height so no space is taken */
overflow: hidden; /* Clip any overflow */
mso-hide: all; /* Hide in Outlook for Windows */
visibility: hidden; /* Additional hide method for compatibility */
opacity: 0; /* Ensure invisible even if display:none fails */
color: transparent; /* Text color transparent as additional fallback */
height: 0;
width: 0;
">Your preheader text goes here — 85-100 characters maximum for mobile.</span>
<!-- Regular email content begins here -->
<table role="presentation" ...>
This implementation uses display:none combined with max-height:0 and overflow:hidden — a combination that hides the preheader text in the visual email body while leaving it accessible to the email client's preview text extraction. The CSS approach is reliable across all major email clients including Gmail, Apple Mail, Outlook on iOS/Android, and Yahoo Mail.
Alternative implementation without CSS (for email systems that strip CSS): place the preheader text inside a spacer table cell with zero-height and width settings. This approach is less elegant but handles email clients that aggressively strip inline CSS.
White-on-White Preheader: Why It Hurts Deliverability
A common preheader technique that predates modern CSS support in email clients: placing the preheader text in a font with white colour (#ffffff) on a white background — making it visually invisible to the reader while still appearing in the email client's preview extraction. This technique works for its intended purpose (hiding the preheader text in the body while making it available for preview) but introduces content scoring problems that the CSS-based approach avoids.
Corporate email gateway filters (Proofpoint, Barracuda, SpamAssassin) specifically flag white-on-white text as a spam signal. The pattern is associated with spam campaigns that hide keywords in white text to manipulate content scoring while showing visible content that appears legitimate. When a legitimate email uses white-on-white preheader text, it scores higher on spam filter content evaluation than the same email without that technique — potentially enough to tip the content score above the gateway's threshold for legitimate commercial email.
The CSS-based approach (display:none + max-height:0) does not create white-on-white text — the text is invisible because it has no height and is hidden, not because it has matching foreground and background colours. This distinction means the CSS approach does not trigger the white-on-white content scoring flag, while the colour-matching approach does.
If an email template currently uses white-on-white preheader implementation, migrating to the CSS-based approach is a straightforward template update that eliminates the content scoring risk without changing the preheader's visual presentation or its preview text behaviour.
Character Length and Client Truncation
Different email clients and devices display different amounts of preheader text before truncating. The practical limits:
| Client / device | Approx characters displayed | Notes |
|---|---|---|
| Gmail (mobile, iOS/Android) | ~75-100 chars | Varies by screen size and font settings |
| Apple Mail (iPhone) | ~90-110 chars | Longer on larger iPhone models |
| Outlook (iOS/Android) | ~75-85 chars | More compact inbox view |
| Gmail (web, desktop) | ~55-80 chars after subject | Depends on subject line length — longer subject = shorter preheader space |
| Apple Mail (desktop) | ~90-120 chars | More display space on desktop |
| Yahoo Mail (web) | ~60-90 chars | Variable based on inbox view mode |
The practical preheader length guideline: write for 85-100 characters total. This length is fully visible on most mobile clients without truncation and provides sufficient content for desktop clients that can display more. For programmatic preheader generation (different preheader per campaign or per-segment), enforce an 85-character maximum in the content generation system to prevent variable-length preheaders that truncate inconsistently across the audience.
The subject line length affects how much preheader is visible in the combined subject + preheader preview. A 60-character subject line leaves more space for preheader text in the combined preview than a 45-character subject line — but in the opposite direction, a 90-character subject line (which itself truncates on mobile) leaves minimal space for preheader content to appear before the combined preview is cut off. Write subject and preheader together, considering how they appear as a combined unit in the inbox list view.
Preheader Impact on Open Rates and Engagement
Preheader's open rate impact is well-documented through A/B testing across commercial programmes. The patterns that consistently emerge: preheaders that extend the subject line's message (rather than repeating it) outperform both no-preheader emails and preheaders that restate the subject. The subject and preheader should feel like the beginning of a sentence that the recipient completes by opening the email.
High-performing preheader patterns: (1) The complementary add: Subject: "Your exclusive offer expires at midnight" → Preheader: "15% off everything — no code needed, just click through before 11:59pm". (2) The specificity add: Subject: "New arrivals you'll love" → Preheader: "3 new collections just added — minimalist, coastal, and garden aesthetics". (3) The curiosity gap: Subject: "We need to tell you something" → Preheader: "And it involves your account and a change we think you'll really appreciate". (4) The social proof: Subject: "Join 50,000 professionals" → Preheader: "The newsletter that 50K marketers read every Tuesday to stay ahead".
Lower-performing preheader patterns: (1) Subject and preheader saying the same thing from different angles — redundancy wastes the second impression opportunity. (2) Generic filler: "Click here to view this email in your browser" — the auto-extracted default text that many senders fail to replace. (3) Legal disclaimers as first content — CAN-SPAM/GDPR required elements should be at the footer, not the preview position. (4) Emoji overload in preheader — works in moderation for consumer brands but reduces perceived professionalism for B2B and financial audiences.
Preheader in Dark Mode
The CSS-based preheader implementation (display:none) is invisible in both light mode and dark mode — the correct behaviour. The white-on-white preheader technique, however, creates a dark mode problem: when the email client inverts colours in dark mode, white text on white background becomes black text on black background — still invisible in dark mode, but only incidentally. In Type 1 dark mode clients that force colour inversion on all email content (some older Outlook versions), white-on-white text may become visible as black text on black background — producing a visible line of preheader text within the email body in dark mode that the sender intended to be invisible. This is a user experience failure specific to the white-on-white implementation that the CSS-based approach does not share.
Testing Preheader Across Clients
Preheader rendering should be tested before any significant campaign deployment, particularly when a new template is being used for the first time. The testing checklist: (1) Verify preheader appears correctly in Gmail mobile (iOS and Android) — the most common mobile email client. (2) Verify preheader appears in Apple Mail on iPhone — the second most common mobile client. (3) Verify preheader is not visible in the email body (the hidden CSS is working). (4) Verify the preheader length is appropriate — not truncating at an awkward mid-word break. (5) In dark mode Apple Mail, verify the preheader text is not visible in the email body.
Commercial testing tools: Litmus and Email on Acid both provide preheader preview across 30+ clients and devices, showing exactly how the subject + preheader combination appears in each inbox list view. For teams without commercial testing tools, manually sending test emails to seed addresses in Gmail (mobile), Apple Mail (iPhone), and Outlook iOS covers the most common client scenarios.
Preheader Best Practices and Common Mistakes
Best practices: Use the CSS display:none implementation (not white-on-white text). Write preheader as the natural continuation of the subject line. Keep total preheader length to 85-100 characters. Write preheader and subject together — they appear as a unit. Test rendering across Gmail, Apple Mail, and Outlook mobile before deployment. Update preheader for every send — a unique preheader per campaign prevents the inbox from showing identical previews for consecutive emails from the same sender.
Common mistakes to avoid: White-on-white text hidden preheader — use CSS methods instead. No preheader at all (letting the client auto-extract first body text). Preheader that repeats the subject line. Preheader longer than 100 characters (the excess is invisible but wastes copywriting effort). Using the preheader for legal disclaimers or unsubscribe instructions — these belong at the footer. Emoji spam in preheader for B2B audiences where it reduces professionalism rather than increasing engagement.
Preheader optimisation is one of the highest ROI email copywriting investments available — a well-crafted preheader adds meaningful open rate lift with minimal production cost. Build preheader writing into the standard campaign production process; test it as part of the pre-campaign checklist; and the combined subject + preheader unit will consistently outperform the subject-only preview that programmes without explicit preheader strategy present to the inbox.
A/B Testing Preheader Variations
Preheader A/B testing produces some of the most reliable open rate data available in email optimisation — the variable is isolated (subject and content remain identical, only preheader changes), the sample sizes are usually sufficient for statistical significance within a single campaign, and the result directly informs the next send's preheader approach. The testing methodology: split the campaign audience into two equal segments, send with Preheader A to segment 1 and Preheader B to segment 2, compare open rates after 4 hours (sufficient for the early-opener population to establish a clear winner). Apply the winning preheader pattern to the next 3-5 campaigns to validate whether the result generalises beyond the single test.
Test one variable at a time within preheader testing. The most valuable preheader tests: (1) Complementary message vs curiosity gap — does extending the subject's direct message outperform a curiosity-creating preheader for this specific audience? (2) Specificity vs urgency — does "3 new products in the collection you browsed" outperform "Offer ends tonight — don't miss this"? (3) Personalisation vs broadcast — does using the recipient's first name or personalised product recommendation in the preheader generate better open rates than a static preheader for the full list? The answers are programme-specific and audience-specific; testing rather than assuming produces the preheader strategy that actually works for the specific audience rather than the one that works on average across all programmes. Build the preheader testing habit into at least one campaign per month and the cumulative open rate improvement will be measurable within a quarter.
A/B Testing Preheader Copy
Preheader is one of the most testable elements in email — the production cost of testing two preheader variants is minimal, and the impact on open rate is measurable within a single campaign's results. The A/B test structure: same subject line, same send time, same audience segment split 50/50. Variant A: preheader that complements the subject with specificity. Variant B: preheader that creates a curiosity gap or adds urgency. Run the test for 4-6 campaigns before drawing conclusions — single-campaign preheader test results have high variance due to content and timing interaction effects. Over 4-6 campaigns, the consistently higher-performing preheader strategy becomes clear from the aggregate open rate data.
For programmes running A/B tests on subject lines simultaneously: avoid testing subject and preheader in the same campaign. The interaction effects between subject and preheader variations make it impossible to attribute performance differences to one variable or the other. Test subject lines in one campaign cycle, preheader strategies in the next. This clean variable isolation produces cleaner data and more reliable conclusions about which copy approaches drive open rate improvement.
Preheader is the element that most senders underinvest in relative to its commercial impact. Subject lines receive careful copywriting attention; preheader receives whatever text first comes to mind or, worse, defaults to the auto-extracted first body content. Elevating preheader to the same copywriting priority as subject line -- writing it deliberately, testing it systematically, and implementing it correctly in CSS -- is one of the highest-return email optimisation investments available at essentially zero incremental production cost.
A/B Testing Preheader Effectively
Preheader A/B testing follows the same principles as subject line testing but requires tracking the combined subject+preheader impression rather than each in isolation. When testing preheader variations, hold the subject line constant and vary only the preheader — this isolates the preheader's contribution to the open rate difference. A meaningful preheader test requires a minimum of 5,000 recipients per variant to produce statistically reliable results at typical open rates. The winning preheader from an A/B test provides the template for future campaigns in that programme type — the pattern that won (curiosity gap, specificity add, social proof) is likely to outperform other patterns consistently for that audience.
Preheader testing should be part of the standard campaign optimisation calendar rather than a one-off experiment. Run preheader tests quarterly — audience preferences for preview content style shift as subscriber tenure lengthens and content familiarity changes. The preheader pattern that outperforms in year one of a newsletter may plateau in year three as the audience becomes familiar with the sender's communication style. Fresh preheader patterns, tested and validated against the current audience, maintain the open rate lift that preheader optimisation provides over the programme's lifetime.
A/B Testing Preheader: What to Measure
The most reliable way to measure preheader impact is controlled A/B testing where subject line and sender are identical, and only the preheader varies. The metric to measure: open rate per delivered message (not per total sent, to account for any deliverability variation). A well-designed A/B test compares a meaningful preheader against a blank preheader (or a preheader that simply repeats the subject) over a sufficiently large sample to detect real differences — typically 10,000+ contacts per variant for statistical reliability.
Additional metrics worth tracking in preheader tests: click rate (does a better preheader that generates more opens also generate proportionally more clicks, or does the open rate lift come from recipients who opened but did not engage further?); complaint rate per variant (lower-quality preheaders that mislead about content can generate higher complaint rates even if they generate higher open rates); and unsubscribe rate. The full picture of preheader quality is not just the open rate lift — it is the downstream engagement quality of the opens that the preheader generates. A preheader that generates 10% more opens but the same or lower click rate may be attracting less qualified openers through misleading preview text, which eventually manifests as higher complaint rates from disappointed recipients.
Preheader optimisation, built into every campaign as standard practice and tested quarterly to validate the programme's preheader formula for its specific audience, compounds into meaningful commercial performance over time. The open rate improvement from preheader optimisation at scale — applied to every campaign across a full year — generates proportionally more revenue from the same list and sending frequency, making it one of the clearest positive-return email marketing investments available.