Updated · 7 min read
Preheader text: the second subject line most programs ignore
Preheader text is free real estate and most programs give it away. Every major inbox client shows it next to the subject line — another 50 to 100 characters to sell the open — and the default output is usually 'View this email in your browser' or whatever alt text happens to sit at the top of the HTML. The subject line is the headline. The preheader is the subhead. Write them as a pair or don't bother sending.
By Justin Williames
Founder, Orbit · 10+ years in lifecycle marketing
What the preheader actually is
The preheader is the first chunk of plain text in your email that surfaces in the inbox preview. Every major client renders it: Gmail desktop shows around 90 characters, Gmail mobile shows about 40, Outlook shows 50, Apple Mail shows up to 140. The client pulls it from the first preview-eligible text it finds in your HTML. If you don't set the preheader explicitly, it'll grab whatever sits at the top of your body — often a logo's alt text or a "view in browser" link. Neither earns anyone's attention.
The subject line is the headline. The preheader is the subhead. If your headline has to stand alone, you've halved the pitch.
Every serious ESP — Braze, Customer.io, Iterable, Klaviyo, you name it — exposes a dedicated preheader field in the email editor. Fill it in. Every time. Leave it blank and the client invents one, and the invented one is almost never the one you'd have chosen if you'd had three seconds to think about it.
On the deliverability question that always comes up: no, preheader doesn't affect filtering directly. Mailbox filters care about subject, sending domain, authentication, body content. What the preheader does do is lift open rate, which feeds engagement signals, which affects future deliverability over weeks and months. Second-order mechanism, real impact.
The pattern that works: subject + preheader as a unit
Write subject and preheader together. Not separately, not in two different sprints, not one by the copywriter and the other by whoever happened to be in the editor. The pair should function as a one-two punch — subject hooks, preheader expands.
,
The shape: subject raises the question, preheader answers half of it, the remaining half is the click. Or the subject teases the outcome and the preheader adds the specific detail that makes it concrete. Either way, they're written in one sitting, not two.
Transactional is where this matters most, and where most programs ignore it hardest. "Your order shipped" plus "Arriving Thursday. Track it here." is immediately useful. "Your order shipped" plus "View in browser" is actively user-hostile. Transactional opens at 3–5× the rate of marketing — the preheader is often the summary a user doesn't even need to open.
What to avoid
Don't repeat the subject.Inbox scanners see subject + preheader together as one line. If the preheader just restates what the subject said, you've wasted the slot and signalled that nobody was paying attention at send time. "Your order shipped" followed by "Your order has shipped." reads as effort taken and wasted.
Don't use hygiene text."View this email in your browser." "Trouble viewing? Click here." Artifacts of a pre-responsive email era that somehow never got removed from the template. The preheader slot is worth more than the web-version link, several orders of magnitude more.
Don't lean on emoji filler.Preheaders stacked with ⭐✨🎁 and no substance read as spammy and test badly every time. Emojis work sparingly as visual anchors. They don't work as the content itself — the reader is scanning for meaning, and meaning is not a party-popper.
Don't rely on the body's first line.Leave the preheader field blank and the client invents something. Usually "[Your Brand] Logo" alt text or a preview-text hack your template inherited from 2017. Neither sells the open. Both embarrass the program.
One more tactic worth retiring: padding the preheader with whitespace or zero-width characters to push hygiene text below the fold. That was a 2016 move. Modern clients have mostly stopped rendering trailing hidden content, and Outlook has a habit of displaying it anyway in ways that read as broken. Just keep the preheader short, intentional, and stop there.
Length and device considerations
Write for mobile first. Gmail mobile truncates around 40 characters. Apple Mail mobile shows 60–80. Desktop clients show 90+. Which means your first 40 characters have to carry the whole message, with the next 50 as reinforcement for the desktop segment that gets the full reveal.
,
The asymmetry is real and it's permanent: most of your audience sees the short version, a meaningful minority sees the long one, and you write for both in a single field. That's the craft.
Testing and iteration
Subject lines get A/B tested constantly. Preheaders rarely do, which is the missed opportunity. Since they appear in the inbox as a pair, the preheader affects open rate almost as much as the subject. Test them together when you can — a 4-arm test of subject A/B × preheader A/B — or at least test preheader variants against a fixed subject to isolate the lift.
The A/B testing playbook has the test-structure mechanics. A good preheader rewrite on a high-volume send typically lifts open rate 5–15%, which is a lot of incremental opens for an hour of writing.
treats subject + preheader pairing as the default output — you don't get a subject without a preheader suggestion attached, because the two were never meant to be separate in the first place.
Frequently asked questions
- What is email preheader text?
- The snippet of text shown in the inbox preview immediately after the subject line. Gmail desktop shows about 90 characters; iOS Mail shows about 40; Outlook web shows about 100. When not set explicitly, mailbox providers pull the first visible text from the email — which often produces useless fallback like "View in browser" or "Hi First Name,". A good preheader extends the subject rather than duplicating it.
- How long should a preheader be?
- Match the most-restrictive client your audience uses heavily. If iOS Mail share is high, write for 40-character visibility. If desktop-dominant, 90 characters. The first 40 characters should carry the hook regardless — anything past 40 is a bonus for clients that show more.
- Should the preheader repeat the subject line?
- No. Repetition wastes the second line of inbox preview real-estate. The preheader's job is to EXTEND the subject: add a hook, specific detail, or reason to open. If the subject says "Your Tuesday delivery is out", the preheader should say "Arriving 2-4pm, leave in mailbox" — not "Your Tuesday delivery is out for delivery."
- How do I hide a preheader after the visible portion?
- Invisible spacer pattern: after the visible preheader text, add 100-200 characters of non-breaking space characters (Unicode U+00A0) inside a div with display:none or color:transparent. This prevents mailbox providers from pulling the first body text into the preview — forcing them to use only your declared preheader. Common implementation: a hidden div with display:none, font-size:1px, line-height:1px, max-height:0, max-width:0, opacity:0, and overflow:hidden.
- Does preheader text affect deliverability?
- Not directly — preheader is a display feature, not a trust signal. But a well-written preheader increases open rate, which increases engagement signals, which feeds reputation over time. Indirect but real. The bigger risk: auto-pulled preheader defaults ("View in browser") that look broken or spammy and depress opens.
Related guides
Browse allEmail dark mode: the four render modes and how to not break any of them
Dark mode in email isn't one feature — it's four different render behaviours across major clients, each with its own logic. Design without knowing which mode you're hitting and roughly half your audience sees something you never approved. Here's what each client does and the defensive rules that survive all of them.
Mobile email design: 65% of opens are on a phone — design for that
Two-thirds of email is opened on mobile. Most designs still start with desktop and hope it collapses. Here are the mobile-first rules that reliably produce emails that read, click, and convert on a phone.
Email accessibility: the seven rules that make your emails readable by everyone
Email accessibility isn't a compliance tax — it's the difference between reaching 100% of your audience and the 85% who have easy sight, steady hands, and full-volume screens. Seven rules cover 90% of what actually matters, and most of them are cheap.
Emojis in subject lines: when they help, when they hurt
One well-placed emoji lifts open rate a few percent. Three reads as spam and drops it. The honest version of the emoji question is smaller and more specific than the debate suggests — here's the pattern that actually survives testing.
Plain-text email versions: why they still matter in 2026
Every HTML email should ship with a plain-text multipart alternative. Most ESPs auto-generate one, and most of those auto-generated versions are garbage. Here's why the plain-text version still matters in 2026 and how to make the version you ship actually work.
Transactional email anatomy: the five sections every transactional needs
Transactional emails open at 3–5x the rate of marketing and carry more brand signal per send than anything else in the program. Most teams treat them as ops artefacts and miss the leverage entirely. Here's the five-section anatomy that works across every transactional type.
Found this useful? Share it with your team.
Use this in Claude
Run this methodology inside your Claude sessions.
Orbit turns every guide on this site into an executable Claude skill — 54 lifecycle methodologies, 55 MCP tools, native Braze integration. Pay what it's worth.