How To Write Better Email Preheaders

An email preheader is the short line of preview text that many inboxes show beside or beneath the sender name and subject line. It is also commonly called preview text. Before a subscriber opens the message, it can help them understand the offer, update or reason to read on.

That makes the preheader part of the inbox experience, rather than a minor setting to complete at the end of production. A clear sender name, an accurate subject line and a useful preheader work together. If one is vague, repetitive or misleading, the whole message has less chance of earning attention from someone who has chosen to receive it.

The objective is not to cram every possible selling point into a limited space. It is to add the most useful next piece of information.

What a preheader should do

A subject line usually carries the main idea. The preheader should normally supply context that the subject does not: the product category, the practical benefit, the audience, a key condition or the specific content inside.

For example:

Subject line	Weak preheader	Stronger preheader
Your October account update	Read the latest news from our team	See the revised billing dates and the action needed before renewal.
New autumn walking guides	Discover our latest collection	Three routes for wet weekends, with maps you can save offline.
Your basket is waiting	Don’t miss out!	The items are still reserved today, including free delivery over £50.
Registration closes on Friday	Book your place now	The final session covers reporting, attribution and campaign QA.

In each stronger example, the preheader advances the message. It avoids merely restating the subject in slightly different words.

Preheaders are especially useful where the subject line needs to be short, branded or functional. A receipt, service notice or password-reset email may have a deliberately plain subject. The preview can then explain what changed or what the recipient should expect without making the subject harder to scan.

Write the subject line and preheader as one unit

Do not write the subject line first and treat the preview as an isolated afterthought. Read the sender name, subject and preheader in sequence, as a recipient would in a crowded inbox.

A practical drafting pattern is:

• Sender: establish who the message is from.
• Subject: state the central news, proposition or task.
• Preheader: provide the detail that makes the subject more meaningful.

Suppose a publisher sends from “Field Notes”. “The winter issue is here” is a serviceable subject, but it says little about the reader’s reward. A preheader such as “Coastal walks, cold-water swimming and a guide to repairing kit” makes the editorial value tangible.

Equally, a retailer might use “20% off selected lighting” as the subject. “Ends Sunday; exclusions include made-to-order fittings” adds relevant terms. It is more useful than “Shop now”, and less likely to leave the recipient feeling that an important qualification was concealed.

Use the pair to resolve ambiguity. If the subject says “A small change to your plan”, the preheader should clarify whether the change concerns price, features, renewal timing or an action the customer must take. Vague language can be appropriate when curiosity is genuinely part of a newsletter’s editorial style, but it is a poor fit for customer communications that affect access, money or deadlines.

Put the most valuable words first

Inbox layouts differ. A desktop application may show more preview text than a mobile app; personal settings, screen width, font size and notification views can reduce it further. There is no character count that reliably guarantees full display everywhere.

Write so that the first phrase remains useful on its own. Put the action, benefit or crucial qualifier at the front, then add supporting detail. Compare:

• Less resilient: “We have been busy behind the scenes preparing a selection of new…”
• More resilient: “Book your Christmas delivery slot now; weekend availability is limited.”

Avoid introductions that consume the preview without communicating anything: “Just a quick note”, “We’re excited to share”, “You won’t want to miss this” and similar phrases. They may be true, but they make the subscriber work to find the point.

This does not mean every preheader should be aggressively transactional. For editorial or community emails, the first words might establish a subject or mood: “Why the local repair café is busier than ever” or “A conversation with the grower behind this month’s coffee.” The same principle applies: lead with meaning.

Be specific without making promises the email cannot keep

The preheader is marketing copy, but it is also a statement about the contents of the message. Accuracy matters. Google’s sender guidance says that message subjects, headers, display names and other message elements should accurately represent the sender and content, and should not be misleading. It also advises senders not to hide content with HTML or CSS. Google’s email sender guidelines

That is a useful standard beyond Gmail. Do not use a preheader to imply urgency that does not exist, a discount that is unavailable to the recipient, or a personal message where the email is plainly a bulk promotion. “Your order is on its way” should only appear when an order has actually shipped. “We need your response” belongs to a message where a response is genuinely needed.

False urgency may produce a short-term lift in opens, but it damages the reader’s ability to judge future messages. For permission-based programmes, trust is a more valuable asset than a marginally more dramatic line of copy.

The same applies to personalisation. Use a first name, location, membership level or product reference only if the data is sufficiently reliable and the reference improves the message. A preheader that exposes a stale preference, incorrect location or oddly specific behavioural assumption can feel more intrusive than helpful.

Prevent accidental preview text

When a sender does not set preview text, some email clients pull copy from the beginning of the message instead. That can produce unhelpful snippets such as “View this email in your browser”, image alternative text, legal boilerplate or navigation links. Mailchimp documents this fallback behaviour and recommends setting preview text deliberately. Mailchimp’s explanation of preview text

The most reliable approach is usually to use the dedicated preview-text field in the email platform, then send a proof to real inboxes. That is preferable to assuming a particular hidden-text workaround will be interpreted consistently by every client.

If your platform does not provide a field, make meaningful text the earliest useful text in the HTML email and test the result. Avoid padding the top of the message with strings of invisible characters merely to stop later content appearing. Such workarounds can fail as inbox rendering changes, may create confusing output and can introduce unnecessary content for assistive technology.

There is also a content decision to make: should the preheader be visible at the top of the opened email? Often, yes. A short, well-written line can serve as a useful introduction above the hero or headline, especially in a newsletter. If it is visible, write it as normal reader-facing copy rather than metadata that only makes sense beside the subject line.

Consider accessibility before hiding anything

Preheader implementation is sometimes treated as a purely visual concern, but the underlying text can affect people using screen readers and other assistive technologies. CSS methods vary in whether they remove text from the accessibility tree or leave it available to be announced. The W3C notes that visually hidden text can be useful in limited circumstances, but can also make an experience overly verbose. W3C guidance on CSS-hidden text

For marketing teams, the practical lesson is simple: do not add a second, hidden mini-advertisement that repeats the visible opening and adds no value once the message is open. If the preheader is exposed to a screen reader, it should be coherent and worthwhile. If it is hidden from assistive technology, do not rely on it to communicate essential information that is absent from the message itself.

Keep the actual email accessible too. Use live text for important information, purposeful image alternative text, readable hierarchy and descriptive calls to action. A polished inbox preview cannot compensate for an email that becomes difficult to understand after it is opened.

Match the preheader to the type of message

The best formula changes with the recipient’s relationship to the email.

Promotions

State the offer and the most decision-relevant condition. “Save 15% on knitwear until midnight; exclusions apply” is clearer than “Something special is waiting.” Where stock, geography, customer status or a minimum spend changes eligibility, do not use the preheader to overstate who qualifies.

Editorial newsletters

Use the preheader as a second headline or a compact contents cue. It can highlight one strong story, name several distinct features, or identify the edition’s theme. Do not try to summarise every article.

Lifecycle and account messages

Prioritise the event and the action. “Your trial ends in seven days; choose a plan to keep project access” tells the subscriber more than a generic “Important account information.” These emails should favour clarity over teasing language.

Event emails

Give a reason to attend or an operational detail that reduces uncertainty: speaker, topic, location, date or registration deadline. For reminders, include what the reader needs next: “Join at 14:00 GMT; your access link is inside.”

Test preheaders as part of campaign QA

A preheader can look perfect in an editor and still show unexpected text in a recipient’s inbox. Test the whole inbox envelope: sender name, subject line, preview text and any emoji or special characters. Check both mobile and desktop accounts where possible, and include the mailbox providers that matter most to your audience.

Quality assurance should also cover personalisation fallbacks. If a field is blank, the preheader must still read naturally. A proof should reveal whether a dynamic product name is too long, whether a time zone is correct and whether an offer condition is present for the selected audience.

When testing alternatives, start with a clear hypothesis. For instance: does stating the practical use case outperform a generic product announcement for recently active customers? Keep the sender identity, audience, timing, offer and subject line stable where possible. Otherwise, an apparent improvement may be caused by a different variable.

Do not treat open rate as the sole verdict. Apple’s Mail Privacy Protection can prevent senders from seeing whether a message was opened, so open data is not a complete record of reader attention. Apple’s Mail Privacy Protection guidance Instead, consider downstream measures appropriate to the message: qualified clicks, registrations, purchases, completed tasks, unsubscribes, complaint signals and longer-term engagement.

Common preheader mistakes

• Repeating the subject word for word. The pair wastes a chance to explain why the message matters.
• Letting “view in browser” become the preview. Set the text intentionally and proof the inbox view.
• Burying the point. Front-load the reason to open because the remainder may be truncated.
• Using bait-and-switch copy. The email should deliver what the preview implies.
• Adding vague urgency. Use a real deadline, constraint or benefit where one exists; otherwise write a direct description.
• Over-personalising. A relevant, dependable detail is useful. A dubious assumption can undermine confidence.
• Relying on untested hidden-text tricks. Use the platform’s supported setting where available and inspect actual inboxes.

When poor preheaders point to a wider problem

Preheaders do not determine inbox placement on their own. Authentication, sending reputation, complaint rates, list quality, message relevance and unsubscribe handling matter far more to whether permission-based email reaches the inbox. Google, for example, requires large-volume senders to personal Gmail accounts to meet requirements around authentication, DMARC alignment, spam rates and one-click unsubscribe for marketing and subscribed messages. Google’s requirements for email senders

However, weak preheaders can be a symptom of a programme that is asking subscribers to open before it has explained why. If campaigns routinely need exaggerated subjects, artificial scarcity or opaque previews, review the audience, frequency, offer and segmentation as well as the copy. Email Foundry’s deliverability work is relevant at that point: it can assess the sending and audience conditions that shape whether well-written campaigns have a fair chance to be seen. It is not a substitute for making the inbox promise worth keeping.

A better preheader is therefore a small but useful discipline: say what the email is about, add a detail the subject lacks, make the first words count and ensure the message fulfils that expectation.

Frequently asked questions

What is the difference between a preheader and preview text?

In email marketing, the terms are often used interchangeably for the snippet displayed in the inbox after or beneath the subject line. Some teams use “preheader” for a visible line at the top of the email and “preview text” for the inbox-only version. What matters is checking how your email platform and target inboxes use the terms.

How long should an email preheader be?

There is no universal length because inboxes, devices and user settings show different amounts of text. Put the key message at the beginning, then keep the rest concise and useful if it is displayed.

Should the preheader repeat the subject line?

Usually no. It should complement the subject by adding a benefit, condition, detail or reason to open. Repetition can make the inbox listing less informative.

Can preheaders improve deliverability?

A preheader is not a direct substitute for sound deliverability practice such as authentication, consent, list hygiene and complaint control. Clear, accurate preview copy can support subscriber expectations and engagement, but it cannot repair poor sending reputation or unwanted email.

Sources and further reading

• Email sender guidelines — Google
• About preview text — Mailchimp
• Use Mail Privacy Protection on iPhone — Apple
• Technique C7: Using CSS to hide a portion of the link text — W3C
• Email testing and QA — Litmus