Email Preheader Text: How to Add Preview Copy That Works

Email preheader text is a small part of an email message with an outsized effect on the inbox view. When it is intentional, it gives recipients useful context before they open; when it is missing, mailbox apps often pull in awkward fragments such as navigation labels, image alt text, or “View this email in your browser.”

A preheader is not a special SMTP header, API parameter, or DNS record. It is usually the first meaningful text found in the HTML or plain-text body of an email. That distinction matters: reliable preheader text comes from sound message construction, not from assuming every mailbox provider supports a proprietary field.

What email preheader text is

Email preheader text is also called preview text or snippet text. It is the short line that many inbox interfaces show near the sender name and subject line. Depending on the client, viewport, device, message list layout, and accessibility settings, it may appear after the subject, below it, or not at all.

Consider this inbox-row example:

• From: Acme Accounts
• Subject: Your password was changed
• Preheader: If you did not make this change, secure your account now.

The preheader extends the subject rather than repeating it. The subject identifies the event; the preheader supplies the next useful detail and, in this case, an appropriate action.

Preheader text is different from several things that sound similar:

There is no universal Preheader: message header defined by the Internet Message Format. Email messages consist of headers followed by a body; mailbox applications decide which body text to display as a preview. That is why placing the intended preview copy near the beginning of the message body is the practical, interoperable approach.

Why add preheader text to transactional messages

Transactional messages often have clear, high-intent subjects: “Verify your email address,” “Your receipt is ready,” or “New sign-in detected.” That does not mean the preview can be left to chance. A recipient scanning a crowded inbox may use the preheader to distinguish a legitimate, timely message from a generic or suspicious-looking one.

A useful preheader can answer one of four questions immediately:

1. What happened? “A new login was detected from Chicago, Illinois.”
2. What does the recipient need to do? “Use this six-digit code within 10 minutes.”
3. What important detail follows? “Your order ships in two packages.”
4. What is the message not? “No action is required if this renewal was expected.”

The goal is clarity, not artificial urgency. A security notice should not use a vague preview such as “Important information inside.” A receipt should not lead with a marketing slogan. And a password reset should not expose the reset token, a full account number, or another secret in a place that might be visible on a lock screen.

Preheaders can prevent accidental or misleading previews

Without deliberate email preheader text, a client may extract the first text it encounters. Common accidental previews include:

• “Having trouble viewing this message? Open in your browser.”
• “Logo Acme Help Center Account Settings.”
• “Download on the App Store Get it on Google Play.”
• “© 2026 Example, Inc. All rights reserved.”
• A long string of whitespace, HTML fallback text, or image descriptions.

These fragments make even a well-written email look unfinished. They can also weaken trust. If the subject says “Your invoice is ready” but the preview says “Follow us on social media,” the message signals that its content was assembled without enough care.

Do not treat previews as a guaranteed engagement lever

A clear preheader can improve comprehension and make the inbox presentation more coherent, but no sender can guarantee an open-rate increase. Mailbox clients vary, recipients have different inbox layouts, privacy features limit measurement, and message relevance has much more influence than a single line of copy.

Treat preheaders as an experience and correctness requirement: ensure that the first text a client is likely to show accurately describes the email. Any engagement benefit is a secondary result of clearer communication.

Write preheader copy that complements the subject

The best email preheader text completes the subject line. It should add information rather than restate the same words with minor changes.

Here are practical examples for common transactional messages:

Aim for an early, complete idea

There is no universal character limit because the visible length changes by mailbox client and screen width. A sensible working range is often roughly 40 to 100 characters, with the most important words placed first. Write a complete, useful thought even if it is truncated after several dozen characters.

For example:

• Better: “Your verification code expires in 10 minutes.”
• Less useful: “Here is the information you requested regarding your…”

The first version delivers the critical fact quickly. The second postpones meaning, so truncation can remove the useful part.

Use variables conservatively

Personalization can make preview text more useful, but it also creates failure modes. A missing variable, unescaped value, unusually long name, or internal identifier can look broken in an inbox list.

Prefer stable values that are validated by your template system:

Subject: Your order #{{order_number}} has shipped
Preheader: Track your {{item_count}} item order; estimated delivery {{delivery_date}}.

Before sending, test the rendered output for recipients with long names, non-Latin characters, empty optional fields, and values containing &, <, >, or quotation marks. Escape untrusted values for HTML. Do not place passwords, magic links, MFA codes, full addresses, or payment details in preheader text.

Match the message’s urgency honestly

Preheaders are especially important for account and security mail because they influence whether recipients recognize the message as legitimate. Be specific without becoming alarmist:

• Good: “A sign-in from a new device was approved at 14:22 UTC.”
• Good: “Use this code to finish signing in. It expires in 10 minutes.”
• Avoid: “URGENT: Your account is in danger!!!”

False urgency can increase complaints and undermine user trust. Transactional messages should be recognizable, direct, and proportional to the actual event.

Add email preheader text in HTML

The most dependable method is to put your intended preheader at the very start of the HTML <body>, then visually hide it in a way that does not depend on a single CSS declaration. The message remains meaningful if a client ignores some styling, and the rest of your email begins with intentional preview content.

Here is a robust baseline pattern:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Your order has shipped</title>
  </head>
  <body style="margin:0; padding:0;">
    <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;"
      aria-hidden="true"
    >
      Your order has shipped. Track delivery and view the latest estimate.
    </div>

    <table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0">
      <tr>
        <td align="center">
          <!-- Visible email content begins here -->
          <h1>Your order is on its way</h1>
          <p>We have handed your package to the carrier.</p>
        </td>
      </tr>
    </table>
  </body>
</html>

This pattern uses several hiding techniques because HTML email clients have uneven CSS support. display:none is helpful where supported; max-height:0, font-size:1px, line-height:1px, opacity:0, overflow:hidden, and mso-hide:all provide additional protection across a fragmented ecosystem. None of these rules is a promise that every client will hide the text identically, so the copy must remain acceptable if it becomes visible.

Put it before logos, navigation, and browser-view links

Source order matters. A preview extractor may take text from the earliest part of the HTML. Put the hidden preheader immediately after <body> and before any of the following:

• “View in browser” links
• Logo image alt text
• Navigation links
• Header utility links
• Hidden responsive navigation
• Legal or unsubscribe text

If your template includes a browser-view link first, do not rely on CSS alone to prevent it from becoming the preview. Move the preheader block before it.

Keep the hidden block simple

Use a plain <div> with actual text. Avoid adding tracking pixels, nested tables, web fonts, images, large blocks of invisible punctuation, or complex conditionals before the preheader. Complexity makes source order harder to audit and can create an inbox preview that differs from the rendered email.

Avoid the old tactic of filling previews with repeated non-breaking spaces, zero-width spaces, or long sequences of invisible characters. Those techniques can leak into the rendered message, confuse screen readers, bloat HTML, and produce odd results in clients that normalize whitespace differently. A short intentional preheader is more durable than preview-padding tricks.

Use a matching plain-text part

Many production emails should use multipart/alternative: one text/plain part and one text/html part that represent the same message. MIME allows multiple representations of the same content, and capable clients generally choose the most appropriate version.

The plain-text part matters for recipients who prefer plain text, clients that do not render HTML, spam and security analysis, forwarding workflows, and some preview extraction paths. Place the text equivalent of the preheader first in the plain-text body.

Your order has shipped. Track delivery and view the latest estimate.

Your order is on its way

We have handed your package to the carrier.
Track your shipment: https://example.com/track/abc123

Do not make the plain-text preheader a radically different claim from the HTML preheader. For example, the HTML version should not say “Delivered tomorrow” while the text version says “Expected this week.” Keep both representations factually aligned.

Example raw MIME structure

An email API will usually build MIME for you. If you send through an SMTP library or construct raw messages yourself, the shape is similar to this:

From: Example Store <orders@example.com>
To: Taylor <taylor@example.net>
Subject: Your order has shipped
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part_12345"

--part_12345
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Your order has shipped. Track delivery and view the latest estimate.

Your order is on its way.

--part_12345
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<!doctype html>
<html>
<body>
<div style="display:none;font-size:1px;color:#fff;line-height:1px;max-height:0;max-width:0;opacity:0;overflow:hidden;mso-hide:all;" aria-hidden="true">Your order has shipped. Track delivery and view the latest estimate.</div>
<h1>Your order is on its way</h1>
<p>We have handed your package to the carrier.</p>
</body>
</html>

--part_12345--

The boundary value must be unique within the message and used consistently. Do not manually assemble MIME unless you understand line endings, transfer encodings, headers, boundaries, and attachment handling. A mature email library or transactional provider’s REST endpoint is usually safer. If you are integrating an application sender, consult the email API reference and setup guides for the provider-specific request format rather than assuming an HTML property is named the same everywhere.

Implement it with an email API or SMTP relay

Preheader text is part of the message body, so the implementation is broadly the same whether your application sends via an HTTP API or SMTP relay.

REST API sending

Most transactional APIs accept separate fields for the subject, HTML content, and plain-text content. The API may be named differently across providers, but the principle is consistent:

{
  "from": "Example Store <orders@example.com>",
  "to": ["taylor@example.net"],
  "subject": "Your order has shipped",
  "text": "Your order has shipped. Track delivery and view the latest estimate.\n\nYour order is on its way.",
  "html": "<!doctype html><html><body><div style=\"display:none;font-size:1px;color:#fff;line-height:1px;max-height:0;max-width:0;opacity:0;overflow:hidden;mso-hide:all;\" aria-hidden=\"true\">Your order has shipped. Track delivery and view the latest estimate.</div><h1>Your order is on its way</h1><p>We have handed your package to the carrier.</p></body></html>"
}

The property names in that example are illustrative. Verify the exact schema, authentication method, endpoint, recipient format, and error response format in your provider’s documentation. Do not invent a separate preheader parameter unless the provider explicitly documents one; even if an API offers one, inspect the delivered HTML and text parts to confirm how it is rendered.

SMTP relay sending

SMTP transports the completed RFC 5322 message. Your application or mail library composes the Subject, From, recipient headers, MIME structure, text part, and HTML part before the relay accepts it.

A successful SMTP submission commonly ends with a reply such as:

250 2.0.0 Message accepted for delivery

That response means the next SMTP server accepted the message for processing. It does not prove that a recipient’s inbox displayed your preheader, that the message reached the inbox instead of spam, or that the recipient opened it.

A temporary response such as 421 4.7.0 or 451 4.7.1 generally indicates a retryable delivery or policy condition. A permanent response such as 550 5.1.1 often indicates an invalid recipient address, while other 5xx replies can reflect policy or authentication problems. Exact text is receiver-specific; log both the three-digit SMTP reply and any enhanced status code, then classify bounces using the provider’s event data and recipient suppression logic.

Rendering errors are not SMTP errors

A message can receive 250 2.0.0 and still show the wrong preview because the HTML source starts with the wrong text. Conversely, a perfect preheader does not fix an SMTP rejection, a failed DKIM signature, an unauthenticated domain, or a recipient mailbox that does not exist.

Keep these layers separate in your monitoring:

• Template correctness: Subject, HTML preheader, visible copy, text part, variables.
• Submission: API response or SMTP acceptance.
• Authentication: SPF, DKIM, and DMARC alignment.
• Delivery outcomes: Delivered, delayed, bounced, complained, suppressed.
• Inbox rendering: Preview text, layout, images, links, dark mode, accessibility.

Avoid common email preheader text mistakes

The following mistakes account for most broken or unhelpful previews.

Repeating the subject line

This wastes the limited preview space:

Subject: Your subscription renewal is complete
Preheader: Your subscription renewal is complete

Instead, add context:

Subject: Your subscription renewal is complete
Preheader: Your next billing date is June 15, and your receipt is ready.

Letting boilerplate win source order

A preheader hidden beneath a logo, a navigation table, or “view online” text may not be the text the inbox extracts. Inspect the final generated HTML—not only the source template—and verify what appears immediately after <body>.

Treating hidden content as a place for secrets

Preheader text may be shown in notifications, lock-screen previews, wearable devices, desktop inbox lists, and forwarded messages. Do not include authentication codes, reset URLs, financial data, sensitive health information, or private account details.

For a sign-in code email, use a safer preview such as “Use the code in this email to finish signing in.” Put the actual code in the body where the recipient expects it.

Hiding content so aggressively that it becomes hostile

A huge invisible text block, keyword stuffing, or deceptive copy can create a poor experience and may look suspicious to filtering systems. The hidden preheader should be a short, honest summary that would be acceptable if a client displayed it in the message.

Forgetting localization

If the subject is localized but the preheader remains in English, the message can look broken before it is opened. Translate the preheader through the same content workflow as the subject and body. Test languages with longer words and right-to-left scripts; a preview that truncates gracefully in English may become awkward in German, Finnish, Arabic, or Hebrew.

Test previews before production sends

An email preview is a mailbox-client behavior, so browser testing alone is not enough. Build preheader checks into template QA and test actual delivered messages.

A practical testing workflow

1. Render the final template with representative data. Include long names, empty optional variables, punctuation, Unicode, and dynamic values.
2. Inspect the raw message source. Confirm that the HTML preheader appears before visible header content and that the text/plain part starts with matching copy.
3. Send to seed inboxes. Check Gmail, Outlook, Apple Mail, Yahoo Mail, and any clients used heavily by your audience.
4. Inspect desktop and mobile views. The amount of visible preview text differs substantially by viewport and app settings.
5. Check the opened message. Ensure hidden preheader text is not visibly creating a gap, white line, or accidental text at the top.
6. Review accessibility. Confirm that the hidden block does not create confusing spoken content in the assistive technology and client combinations your organization supports.
7. Run deliverability checks separately. Use tools such as mail-tester.com to inspect message construction and authentication, and MXToolbox to review DNS records and lookup results.

A third-party rendering platform can also help test client-specific layout. The important discipline is to test a delivered message, not just a screenshot produced from a browser rendering engine.

Inspect raw source in a mailbox

When an inbox preview is wrong, open the original message source and search for the unexpected phrase. If “View in browser” appears in the preview, locate that phrase in the source and compare its position with your intended preheader. The diagnosis is usually straightforward: the extractor found another text node first, or the template system omitted the preheader for that message variant.

Check both the raw HTML and the plain-text part. Some templating systems generate them in separate code paths, which can result in a correct hidden HTML preheader but an outdated text preview.

Keep preheaders separate from deliverability authentication

Email preheader text affects presentation in the inbox list. Domain authentication affects whether a receiver can verify who sent the message and how it should handle unauthenticated mail. Both matter, but they solve different problems.

For production transactional email, configure authentication for the domain that appears in your visible From: address. Current mailbox-provider sender guidance commonly expects SPF or DKIM for all senders and SPF, DKIM, and DMARC for higher-volume senders. A preheader cannot compensate for failed authentication.

Representative DNS syntax

Your provider will supply the exact hostnames and values for its infrastructure. Do not copy another sender’s include domain or DKIM public key. The following examples show the general shape of real DNS TXT records using the reserved documentation domain example.com.

SPF at the root domain:

example.com. IN TXT "v=spf1 ip4:198.51.100.0/24 -all"

In a real deployment, replace the documentation IP range with your authorized sending infrastructure or the provider-specific include: mechanism supplied by your email service. Publish only one SPF TXT record per domain; combine authorized mechanisms into that single record rather than adding several separate v=spf1 records.

DKIM under a provider-selected selector:

s1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=BASE64_ENCODED_PUBLIC_KEY"

The selector (s1 above), algorithm, and key value must match the signing configuration. Many providers use CNAME records for delegated DKIM rather than a direct TXT record. Follow the exact record type and target provided for your sending domain.

DMARC at _dmarc:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Start with an appropriate monitoring policy only after verifying the record with your own security and deliverability process. DMARC depends on identifier alignment, not merely the presence of a DNS record. If your visible From: domain is example.com, make sure the authenticated SPF or DKIM identity aligns according to your chosen alignment settings.

Marketing headers do not belong on every transactional email

Do not add promotional-list headers merely because you are improving previews. List-Unsubscribe and RFC 8058 one-click unsubscribe signaling are intended for list mail. Password resets, receipts, account alerts, and similar event-driven transactional messages have a different purpose. If a message contains marketing content or is part of a subscription list, apply the relevant legal, policy, and mailbox-provider requirements to that stream rather than mixing it indiscriminately with critical transactional mail.

Build a reusable preheader component

Teams often break previews because each template handles them differently. A shared component or helper makes correct source order the default.

A simple template abstraction might look like this:

{{#if preheader}}
  <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;"
    aria-hidden="true"
  >
    {{preheader}}
  </div>
{{/if}}

Place the component immediately after <body> in your base layout. Require every production template to supply a preheader value, while allowing an explicit, reviewed exception for rare message types where a preview would add no value.

Add template-level validation

A good sending pipeline can enforce simple rules before messages are accepted for delivery:

• Reject missing preheader values for templates that require them.
• Reject unresolved tokens such as {{first_name}} or ${order.id}.
• Limit preheader length based on your editorial standard.
• Escape dynamic values for HTML.
• Ensure the text-only part begins with equivalent summary copy.
• Block secrets and sensitive fields from preheader variables.
• Snapshot-test the beginning of rendered HTML to verify source order.

This is especially useful if your application supports both REST API sending and SMTP relay submissions. The channel can differ, but the canonical rendering step should produce the same subject, text content, and HTML content.

Monitor results without overinterpreting open rates

Preheaders are seen before an open, but open tracking is increasingly imperfect. Image proxying, privacy protections, blocked images, and client behavior can all distort open metrics. Do not use a small change in reported opens as definitive proof that one preview is universally better.

Instead, use a broader quality signal set:

• Template render tests pass for each locale and message variant.
• Seed inboxes show an accurate preview instead of boilerplate.
• Recipient support tickets do not report confusing account or security emails.
• Spam complaints remain low and stable.
• Delivery, bounce, and suppression metrics remain healthy.
• Authentication results are passing and aligned.

For a high-volume product email program, compare variants carefully and only when the message purpose, audience segment, send timing, sender identity, and subject line are controlled. A preheader test that changes multiple variables at once cannot tell you what caused any observed difference.

A production checklist for email preheader text

Before enabling a new transactional template, verify the following:

• The preheader adds context instead of repeating the subject.
• It appears as the first meaningful text in the HTML <body>.
• It is short, truthful, and useful even if truncated.
• It contains no passwords, codes, reset links, or sensitive data.
• It is visually hidden without relying on one CSS rule.
• It remains acceptable if a client displays it visibly.
• The plain-text part begins with matching summary copy.
• Browser-view links, navigation, and logo alt text occur after it.
• Variables are rendered, escaped, localized, and tested.
• A delivered message was checked in representative inboxes.
• SPF, DKIM, and DMARC are configured for production sending.
• API and SMTP responses, bounces, and suppressions are monitored separately from rendering quality.

The underlying principle is simple: write the first text in the message as though a recipient might see it before anything else—because many will.

FAQ

Is email preheader text an email header?

No. Despite the name, preheader or preview text is usually extracted from the beginning of the email body by the receiving mailbox application. It is not a standard Preheader: field in the message headers.

How long should email preheader text be?

There is no fixed cross-client limit. Aim for a concise, complete thought—often around 40 to 100 characters—and place the essential information first so it remains useful when truncated.

Can I add preheader text through SMTP?

Yes. SMTP transports the message you compose. Add the intended text at the beginning of the HTML body, provide a matching opening line in the plain-text part, and send the resulting MIME message through your SMTP relay.

Why does my inbox show “View this email in your browser” as the preview?

That phrase is probably the first text your mailbox client extracted from the message source. Put the intended hidden preheader immediately after the opening <body> tag, before browser-view links, logos, and navigation.

Does preheader text improve deliverability?

Not directly. A useful preheader improves the inbox presentation and recipient understanding, while deliverability depends on factors such as sender reputation, consent, content, recipient engagement, SPF, DKIM, DMARC, and mailbox-provider policies.