Email Preheader: Definition, Examples, and Best Practices

An email preheader is the short preview text that appears beside or beneath an email’s subject line in many inboxes. Also called preview text, snippet text, or a Johnson box, it expands on the subject line before a recipient opens the message. A strong preheader makes the inbox listing clearer, more relevant, and more compelling.

What is an email preheader?

An email preheader is the text an inbox displays with the sender name and subject line before the recipient opens an email. In many email clients, it appears as a muted-gray line below the subject line on mobile or beside it on desktop. Its job is simple: add useful context that helps a person decide whether to open, ignore, archive, or delete the message.

The term can describe two closely related things:

• Inbox preview text: The snippet a recipient sees in an inbox list.
• Preheader content in the email HTML: Text placed near the beginning of an email’s body so inboxes can use it as preview text.

In everyday email work, “preheader” and “preview text” are often used interchangeably. Technically, the inbox controls the rendered preview, while the sender supplies text that gives the inbox a strong candidate to display.

For example, consider this inbox entry:

• From: Northstar Outfitters
• Subject: Your trail gear is ready for spring
• Preheader: New waterproof layers, member pricing, and free returns through Sunday.

The subject line introduces the topic. The preheader answers the natural follow-up question: “What is in it for me?” Together, they form a compact message before the email body is ever loaded.

An email preheader is not the same as the technical message header. Email headers contain routing and authentication information such as From, To, Date, Message-ID, and authentication results. The preheader is audience-facing marketing or transactional copy. It may be visible only in the inbox, visible at the top of the opened message, or intentionally hidden in the opened email while remaining available to inbox preview systems.

Why email preheaders matter

The inbox is a decision surface. Before recipients see a hero image, product grid, or call-to-action button, they usually see a sender name, a subject line, and—where supported—a preview snippet. That means the preheader participates in the first impression of a campaign or transactional email.

A preheader matters for campaign performance because it can:

• Clarify a vague, short, or curiosity-based subject line.
• Add a concrete benefit, deadline, price point, or next step.
• Reduce uncertainty about why the recipient is receiving the message.
• Reinforce relevance for a specific audience segment.
• Prevent accidental or low-value copy from becoming the inbox preview.
• Make a subject line and sender name work as one coherent unit.

It extends the subject line rather than repeats it

A common mistake is treating the preheader as a second subject line. If both lines say the same thing, the sender uses valuable inbox space without adding information.

Weak combination:

• Subject: 25% off everything today
• Preheader: Get 25% off everything today.

Better combination:

• Subject: 25% off everything today
• Preheader: Use code WEEKEND25 before midnight; exclusions are listed inside.

The second version introduces urgency, a code, and a practical expectation. It also helps a recipient decide whether the offer applies to their needs before opening.

It supports engagement, not authentication

An email preheader does not directly establish sender identity, authenticate a domain, or determine whether mail passes SPF, DKIM, or DMARC. It is not a standalone deliverability control. A well-written preheader cannot compensate for poor list quality, high complaint rates, weak domain reputation, unauthenticated sending, or unwanted mail.

However, it can indirectly support long-term sending health. When recipients better understand an email’s purpose before opening, they may be more likely to engage appropriately and less likely to mark it as spam because the message feels misleading or unexpected. That relationship is indirect and depends on the whole program: consent, frequency, segmentation, sender recognition, message quality, and post-open experience.

It is especially important on mobile inboxes

Mobile inboxes give people a fast, compressed view of their messages. In that environment, recipients may scan the first few visible words of each sender, subject, and preview line. The exact amount of text varies by device, app, screen size, font settings, conversation view, and inbox configuration, so no fixed character count is guaranteed.

That variability is why the beginning of the preheader matters most. Put the essential meaning first. Do not rely on the last words of a long line to carry the offer, condition, or deadline.

How inboxes create preview text

There is no universal rule that forces every email client to display a preheader exactly as the sender intended. Different inboxes can extract, truncate, rearrange, omit, or replace preview text. An email that looks polished in one inbox may show a shortened, awkward, or unexpected snippet in another.

Many inboxes derive preview text from the first meaningful text in the HTML part of an email. If a sender has not supplied controlled preheader content, the inbox may pull text from whatever appears first, including:

• “View this email in your browser.”
• Navigation links such as “Shop new arrivals” or “Manage preferences.”
• Image alternative text.
• A logo label.
• A web-font fallback message.
• Legal copy.
• A heading that makes little sense without visual context.
• Empty spacing characters or repeated hidden filler.

That behavior explains why a preheader should be planned during email production, not added as an afterthought after the main design is complete.

The sender controls the input, not every rendering detail

A sender can write dedicated preview text and place it at the start of the HTML, but the recipient’s email client still decides whether to display it and how much to show. Inboxes may present the line beneath the subject, next to it, in a notification, or not at all. They may also suppress preview text in some views, such as conversation threads or certain notification settings.

The practical implication is straightforward: make the email preheader useful, but do not put critical instructions only in it. A promo code, required security action, legal disclosure, or appointment detail must also appear clearly in the email body.

HTML and plain-text parts can affect the result

A well-built email commonly includes both an HTML version and a plain-text version. The HTML version allows layout, branding, buttons, and images. The plain-text version supports recipients and clients that prefer or require text-only content.

Preview behavior differs among clients. Some may pull from HTML text, some may use the plain-text part in particular circumstances, and some can behave differently depending on the message structure. This is one reason the first sentence of the plain-text alternative should also be meaningful and aligned with the intended preview.

For a password reset email, for example, a sensible plain-text opening is:

Use this link to reset your Northstar account password. It expires in 30 minutes.

That is better than beginning with a decorative brand slogan, a boilerplate browser-view instruction, or a raw URL without context.

Email preheader versus subject line, inbox snippet, and header

Email terminology can be confusing because several related concepts sound similar. Separating them helps teams write better copy and developers implement it correctly.

Subject line

The subject line is the email’s primary inbox headline. It is sent in the message’s Subject header field and is normally highly visible in inbox lists and notifications.

Example:

Your April invoice is ready

Email preheader or preview text

The preheader is the supporting preview copy shown by many inboxes. It is generally drawn from the earliest available message content or supplied through an email platform’s preview-text setting.

Example:

Download the PDF, review your charges, or update billing details before April 18.

Visible preheader

A visible preheader is actual content at the top of the opened email. It may contain a browser-view link, a short summary, a preference-center link, or a combined utility row. Because recipients can see it after opening, it should be useful and visually intentional.

Hidden preheader

A hidden preheader is placed early in the HTML but styled so it generally does not appear in the opened email. It exists to influence the inbox preview. Hidden preheaders are common, but they require careful testing because HTML email rendering differs across clients.

Email header

An email header is technical metadata used to describe and route the message. It includes fields such as From, To, Reply-To, Subject, and Date; it can also include mail-transfer and authentication data. An email preheader is not an email header in this technical sense.

How to write an effective email preheader

The strongest email preheaders are specific, complementary, and honest. They work with the sender name and subject line as a three-part message, rather than as isolated fields written by different people.

Before writing, ask one question: What extra detail would make the right recipient more confident that this email is worth opening now?

That detail may be a benefit, a deadline, a price, a product category, a status update, a location, an action required, or a clear reason for the message.

Lead with the value or action

Inbox space is limited and variable. Start with the material a recipient should understand even if the rest is truncated.

Instead of:

We are excited to let you know that our spring collection, which includes new outerwear and footwear, is now available for our members.

Try:

New spring outerwear is live—members get free two-day shipping through Friday.

The improved version front-loads the product category and benefit. It does not depend on the recipient reaching the end of the sentence.

Use the preheader to resolve ambiguity

Subject lines can be short, branded, playful, or intentionally incomplete. The preheader should make them clearer.

Examples:

The goal is not to manufacture pressure in every message. It is to give an accurate reason to open.

Match the content to the message type

Campaign email and transactional email need different kinds of preheader copy.

For promotional campaigns, emphasize the offer, category, audience benefit, or time window:

• Save 20% on carry-on luggage through Sunday night.
• Meet three lightweight layers built for changing weather.
• Your member-only early access starts now.

For lifecycle messages, emphasize status and next step:

• Confirm your email address to finish setting up your account.
• Your trial ends in three days; choose a plan to keep your workspace active.
• We noticed you have not signed in recently—here is what changed.

For transactional email, prioritize clarity over persuasion:

• Your receipt for $48.00 is attached to this confirmation.
• Reset your password within 30 minutes using the secure link inside.
• Your shipment left our warehouse and is scheduled for delivery tomorrow.

A transactional preheader should never obscure an important account or security event with promotional language.

Avoid false urgency and bait-and-switch copy

Preheaders should accurately reflect what recipients will find after opening. “Last chance” should mean that the stated deadline is real. “Your order is on the way” should only be used after fulfillment actually reaches that status. “Important account notice” should not be a thin wrapper around an offer.

Misleading inbox copy may produce a short-term open-rate increase, but it can reduce trust, increase negative reactions, and make recipients less likely to engage with future messages. A sender’s reputation is built over repeated interactions, not a single campaign.

How long should an email preheader be?

There is no single correct preheader length because inboxes show different amounts of text. A practical target is to write one concise sentence, usually around 35 to 90 characters, while treating the first 35 to 50 characters as the most important portion.

That is not a strict platform limit. It is a writing discipline. The objective is to deliver the central idea quickly and allow additional text only when it adds real value.

Write for truncation

Recipients may see only part of the sentence. Therefore, the opening words should stand on their own.

Less resilient:

This weekend, after months of planning and conversations with our product team, we are introducing a new way to save.

More resilient:

Save 15% this weekend on our new travel organizers.

The second version communicates the offer and product even if the visible preview ends early.

Do not fill unused space with meaningless characters

Some email developers add nonbreaking spaces, zero-width characters, or other filler after the preheader to prevent inboxes from pulling navigation or body text into the preview. That technique can sometimes reduce unwanted spillover, but it should be used cautiously. Excessive hidden characters can create rendering, accessibility, maintainability, or quality-assurance problems.

A better first step is to make the early HTML content intentional: put useful preview text first, avoid unnecessary boilerplate before it, and test the resulting inbox display. If additional padding is used, keep it restrained and validate it across relevant clients.

How to add an email preheader in HTML

Most email platforms offer a dedicated preview-text field in their campaign editor. When that field is available, use it before modifying template code. It reduces implementation risk and makes the text easy for marketers to review, localize, personalize, and test.

When you are sending custom HTML through SMTP or an API, you may need to include the preheader in the email markup yourself. The basic strategy is to place meaningful text immediately after the opening <body> tag and apply conservative styles that keep it from disrupting the opened-email layout.

Here is a common hidden-preheader pattern:

<body>
  <div style="display:none; font-size:1px; color:#ffffff; line-height:1px; max-height:0; max-width:0; opacity:0; overflow:hidden; mso-hide:all;">
    Your new invoice is ready—review charges and download the PDF.
  </div>

  <table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
    <tr>
      <td>
        <!-- Main email content -->
      </td>
    </tr>
  </table>
</body>

This example is intentionally simple. The combination of display:none, constrained dimensions, opacity:0, overflow:hidden, and mso-hide:all is used because email clients do not all honor the same CSS. Even then, no code pattern is guaranteed everywhere, so testing is part of implementation rather than an optional final step.

Keep the hidden preheader semantically safe

A hidden preheader often repeats information available elsewhere in the email. If it is hidden only visually but announced by a screen reader, a recipient using assistive technology may hear duplicate copy before the actual message begins. Conversely, adding aria-hidden="true" removes content from the accessibility tree but should be used only for non-interactive, duplicated content.

Do not put a link, button, required instruction, one-time passcode, or essential legal information only in a hidden block. Anything important must be present in readable, accessible message content.

Use visible preheaders when they genuinely help

A visible preheader can be a better design choice when it provides utility. For example:

<tr>
  <td style="padding:12px 24px; font-family:Arial, sans-serif; font-size:12px; line-height:18px; color:#666666;">
    New arrivals for warmer weekends. <a href="https://example.com/view-online" style="color:#666666;">View online</a>
  </td>
</tr>

In this pattern, the recipient sees a useful summary after opening, and the inbox has meaningful early text to draw from. The trade-off is visual space at the top of the email. Whether that space is worthwhile depends on the template, message purpose, and audience expectations.

For teams sending programmatically, keep preheader content as a first-class template variable. A reliable template workflow should let a sender define separate values for:

• Sender name
• Subject line
• Preheader text
• Plain-text opening
• HTML headline
• Primary call to action

Treating those elements separately avoids an all-too-common problem: a polished email body paired with forgotten preview text. Consult the email API reference and setup guides when mapping template variables and HTML content into your sending workflow.

Common email preheader problems and their causes

A poor preheader is usually not a deliverability failure. It is a production, copywriting, template, or testing failure. The message may be delivered successfully while the inbox preview still looks unhelpful.

Problem: “View this email in your browser” appears in the inbox

Cause: A browser-view link is the first text in the HTML, and no intentional preview text appears before it.

Fix: Add dedicated preheader text before the browser-view link, or rewrite the visible top row so useful message copy comes first. Keep the browser link if your audience needs it, but do not let it consume the main preview opportunity.

Problem: Navigation labels become the preview

Cause: The template starts with a logo, menu, or linked category labels such as “New | Women | Men | Sale.” Inboxes extract that early text because they do not find a controlled preheader first.

Fix: Insert an intentional preheader block at the start of the body. Also review whether your navigation is necessary in the email at all, particularly for a transactional message.

Problem: The preheader repeats the subject line

Cause: Copy was entered quickly, inherited from a template, or written without viewing the sender-subject-preheader combination.

Fix: Assign each element a distinct role. The sender establishes identity, the subject states the primary idea, and the preheader adds a practical reason, detail, or next step.

Problem: A preheader is blank in some inboxes

Cause: The email client may not show preview text in that view, the app may truncate it aggressively, the HTML may be malformed, the message might be text-only, or an inbox may choose different source content.

Fix: Confirm that the message is valid multipart email, test the HTML and plain-text parts, move useful content earlier in the message, and accept that previews cannot be controlled universally. The subject line must still communicate the core message independently.

Problem: The preview shows odd characters, ellipses, or body text after the intended copy

Cause: The inbox is filling available preview space with additional early content. It may append navigation text, alt text, or body copy after a short preheader.

Fix: First, lengthen the actual preheader with useful supporting detail. Then test whether limited padding after the text improves the result. Do not hide a large amount of irrelevant material merely to force a visual result in one client.

Problem: Personalization looks broken

Cause: A merge variable is empty, incorrectly formatted, unavailable for a recipient, or inserted into the wrong sending field.

Fix: Define a fallback value and test with records that have complete, partial, and missing data. For example, instead of relying on Hi {{first_name}}, use a template rule that can safely render Hi there when a first name is unavailable.

Problem: The preview makes a transactional email look promotional

Cause: A shared template uses sales-oriented preheader defaults for all mail types.

Fix: Maintain separate transactional and marketing templates. Account-security, billing, receipt, and password-reset messages should state the event and action plainly.

Testing an email preheader before sending

Testing should happen at two levels: content review and rendering review. Content review ensures the copy communicates the right thing. Rendering review verifies that the actual message structure produces a sensible inbox snippet across the clients that matter to your audience.

Review the complete inbox line

Do not approve a preheader in isolation. Read it together with the sender name and subject.

For example:

• Sender: Elm & Pine
• Subject: Your cart is waiting
• Preheader: The linen shirt in your size is still available through tonight.

This combination is coherent. Now compare it with:

• Sender: Elm & Pine
• Subject: Your cart is waiting
• Preheader: View this email in your browser.

The second combination wastes a valuable message surface even though the subject itself is acceptable.

Use a realistic seed list

Send tests to accounts that reflect your audience’s likely inbox mix. Include at least a few popular webmail, mobile, and desktop environments used by your customers. If your business audience commonly uses corporate desktop mail clients, test there. If your audience is mobile-heavy, test major mobile apps and devices.

A test list should also include different recipient-data states when personalization is involved:

1. A record with every expected field populated.
2. A record with a missing first name or optional attribute.
3. A record with longer values, such as a long city or product name.
4. A record in each language or locale you support.
5. A record with an order, invoice, or event value that resembles production data.

Test the opened email as well as the inbox

A hidden preheader can render unexpectedly in some clients. Look for tiny visible text above the email, strange spacing, white text on a dark background, duplicate copy, or extra whitespace. Check both light and dark modes where relevant, because a preheader styled white to disappear on a white background can become visible if a client changes background colors.

Also verify that your preheader does not produce a confusing experience in the plain-text part. A recipient who reads plain-text mail should receive a coherent first sentence, not hidden-preview implementation artifacts.

Measure the result carefully

Preheaders influence the decision to open, but they are not the only variable. If you test them, change as little else as possible. Keep the sender name, sending time, audience, subject line, offer, and email body consistent where feasible.

A simple A/B test might use:

• Version A preheader: Free shipping ends tonight at 11:59 p.m.
• Version B preheader: New lightweight jackets are ready for spring travel.

Both versions should match the message content. Interpret results in context: an apparent winner may reflect audience mix, timing, statistical noise, or a subject-and-preheader interaction rather than a universally better sentence.

Open tracking is also imperfect. Privacy features and image-loading behavior can make open rates less precise than clicks, conversions, replies, purchases, or completed account actions. Use opens as directional evidence, not the only proof that a preheader is working.

Practical email preheader examples

The following examples show how different message categories can use preview text. Each preheader adds something the subject does not already say.

Ecommerce promotion

• Subject: Spring layers, 20% off
• Preheader: Lightweight jackets and packable shells are included through Sunday.

Back-in-stock alert

• Subject: It is back in your size
• Preheader: The charcoal weekender is available now; stock is limited.

Order confirmation

• Subject: Order #48172 confirmed
• Preheader: We received your order for $86.40 and will email tracking when it ships.

Shipping update

• Subject: Your package is on the way
• Preheader: Track delivery now; your estimated arrival is Thursday.

Account verification

• Subject: Confirm your email address
• Preheader: Verify your address to activate your account and protect future access.

Password reset

• Subject: Reset your password
• Preheader: Use the secure reset link within 30 minutes if you requested this change.

Product announcement

• Subject: Meet the new reporting dashboard
• Preheader: Build scheduled reports, share saved views, and monitor key trends faster.

Webinar invitation

• Subject: Live workshop: building reliable email flows
• Preheader: Join us Thursday at 1 p.m. ET for templates, testing tips, and Q&A.

Renewal reminder

• Subject: Your plan renews soon
• Preheader: Review your seats and billing details before your renewal on June 1.

Re-engagement email

• Subject: Still want updates from us?
• Preheader: Choose the topics and frequency that make our emails more useful to you.

The common thread is specificity. The recipient can understand the message category and likely benefit without opening. That clarity is useful whether the recipient opens immediately or returns to the message later.

A preheader workflow for developers and email teams

A dependable preheader process should be part of template design, campaign creation, and release checks. It should not depend on someone remembering a hidden field five minutes before a send.

Build it into the template schema

For every reusable email template, define a required or strongly encouraged preheader field. A conceptual payload might look like this:

{
  "from": "Northstar <updates@news.example.com>",
  "to": "alex@example.net",
  "subject": "Your April invoice is ready",
  "preheader": "Download the PDF and review your charges before April 18.",
  "template": "monthly-invoice",
  "data": {
    "invoice_number": "INV-10482",
    "amount": "$48.00",
    "due_date": "April 18"
  }
}

The exact API field names vary by provider and implementation. The important design principle is to make the preheader explicit in your own application model rather than assuming the first line of rendered HTML will always be suitable.

Establish fallback rules

Not every message needs custom creative copy. For high-volume transactional mail, a rule-based fallback can be safer than an empty or accidental preview.

Examples:

• Receipt: Receipt for {{amount}} from {{brand_name}}.
• Password reset: Use this link to reset your password within {{expiry_period}}.
• Invitation: You were invited to join {{workspace_name}}.
• Shipping update: Your order is in transit; track the latest delivery estimate.

Fallbacks should be grammatically complete when data is missing. Avoid producing lines such as Your order for is confirmed or Hi , your invoice is ready.

Make localization deliberate

Preheaders are short, but they still require localization. Word order, date format, currency placement, politeness level, and text expansion differ among languages. A preheader that fits neatly in English may become much longer in German, Finnish, French, or Portuguese.

Do not truncate localized strings manually just to satisfy an assumed character limit. Write clear localized copy, front-load the important idea, and test representative languages in the inboxes your recipients use.

Put preheader checks in quality assurance

Before production sends, include these checks:

• Is preview text intentionally set for this message?
• Does it add information beyond the subject line?
• Does it match the actual email content and offer conditions?
• Does it render safely when recipient attributes are missing?
• Does the first plain-text sentence also make sense?
• Does the test email avoid browser-link or navigation leakage?
• Has the message been checked in priority email clients?
• Are security and transactional emails clear without promotional language?

This checklist takes little time, but it prevents a highly visible class of email mistakes.

Email preheader best practices checklist

Use this list as a final review before launching a campaign or deploying a transactional template.

• Write the subject line and preheader as a pair.
• Place the core value, event, or action in the opening words.
• Add new information instead of repeating the subject line.
• Use one concise, natural sentence.
• Keep promises, deadlines, pricing, and availability accurate.
• Make the preview fit the email type: promotional, lifecycle, transactional, or security.
• Ensure the first content in both HTML and plain text is meaningful.
• Avoid allowing “view in browser,” navigation, or legal copy to become the preview.
• Use a tested preheader implementation in custom HTML templates.
• Do not put essential content only in hidden preview text.
• Test personalization fallbacks and localized versions.
• Review the sender name, subject, and preheader together in a real inbox.
• Measure downstream outcomes such as clicks, conversions, purchases, and completed actions—not only opens.

The bottom line on email preheaders

An email preheader is a small line of text, but it occupies premium inbox real estate. It gives senders a chance to make the subject line more concrete, clarify why the message matters, and stop accidental template text from representing the campaign.

It is not a magic deliverability lever, and it cannot repair weak consent, bad targeting, poor authentication, or unwanted email. Its value is more practical: it helps a legitimate, relevant message make sense at the exact moment a recipient is deciding whether to engage.

The best approach is to treat preheader text as a planned part of every send. Write it alongside the subject line, include it deliberately in templates, make the first HTML and plain-text content useful, test it across important inboxes, and keep the promise it makes after the recipient opens.

FAQ

What is an email preheader?

An email preheader is the short preview text displayed with an email’s sender name and subject line in many inboxes. It provides extra context before the email is opened and is also called preview text, snippet text, or a Johnson box.

Is an email preheader the same as a subject line?

No. The subject line is the main inbox headline sent in the email’s Subject field. The preheader is supporting copy that many inboxes show beside or beneath that subject line. It should complement the subject rather than repeat it.

Does an email preheader affect deliverability?

Not directly. Preheader text does not authenticate mail or determine inbox placement on its own. It can indirectly support healthier engagement by making messages clearer and more relevant, but consent, authentication, reputation, list quality, and recipient behavior remain more important deliverability factors.

What should I do if my preheader shows “View this email in your browser”?

Add intentional preview text at the beginning of the email’s HTML before the browser-view link, or adjust the top of the template so useful copy appears first. Then send tests to confirm that priority inboxes display the desired snippet.

How many characters should an email preheader be?

There is no universal limit because visibility differs by device and email client. Aim for a concise sentence, often about 35 to 90 characters, and put the essential message in the first 35 to 50 characters so it remains useful when truncated.