Email Preview Text: The Preheader Guide for Marketers

Email preview text is the snippet most inbox clients show beside the subject line. It is pulled from your HTML unless you set a dedicated preheader element, so left alone it often shows "View this email in your browser" or a raw merge tag. Written on purpose, it becomes the second line of one inbox sentence.

Key Takeaways

• Preview text is the third part of the inbox unit: sender name, subject line, and the preview snippet shown by most clients.
• Most clients show roughly 35-50 characters before truncating, so front-load the most important words and treat the rest as a desktop bonus.
• The classic failure is letting the first renderable body text leak in, such as a browser link, unsubscribe line, or empty whitespace.
• A hidden preheader div with zero-width padding lets you control the snippet across Mailchimp, HubSpot, Klaviyo, and raw HTML.
• With Apple Mail Privacy Protection inflating opens, judge preview text by click and reply rate, not opens alone.
• A/B test preview text separately from the subject line so you learn which line actually drove the engagement.

What Is Email Preview Text and Where Does It Come From?

Preview text is the short line most email clients render next to or under the subject line in the inbox. Gmail, Apple Mail, and Outlook all show some version of it. It is the reader's first hint of the body before they open the message.

By default the client grabs the first renderable text in your HTML body. If your template starts with "View this email in your browser" or an unsubscribe link, that becomes your preview. If the first thing is a big image, the client falls back to an alt string or to nothing. You only get a clean snippet when you deliberately place a preheader element before the rest of the content.

What Are the Three Parts of the Inbox Unit?

The inbox row is a single unit with three parts: the sender name, the subject line, and the preview text. Readers scan them together as one sentence, not as three disconnected labels. If the subject says "Your weekly report" and the preview says "Unsubscribe from this list", you have written one sentence that ends in a dead end.

Treat the three as one sentence. The sender establishes who is talking, the subject states the promise, and the preview pays off or extends that promise. A subject of "We shipped something for you" paired with a preview of "The new export button is live in your dashboard" reads as a complete thought. The same subject with a preview of "Having trouble viewing this email?" reads as a mistake.

How Many Characters of Preview Text Should You Write?

Character budgets vary by client and device. Apple Mail on desktop shows roughly 50-60 characters. Gmail shows about 45-55 in list view and more in expanded view. Mobile clients show roughly 35-50 characters before cutting off. Outlook on desktop is closer to 35 characters in the reading pane.

Because the smallest budget is around 35 characters, write a front-loaded snippet of 35-50 characters that makes sense on its own. Put the key phrase first. Then add a longer tail of another 40-90 characters that survives on desktop but truncates gracefully on mobile. The truncation should never land mid-thought; it should drop a bonus, not the core message.

What Are the Classic Preview Text Failure Modes?

• "View this email in your browser" leaking in from the top of the template.
• "Unsubscribe" or preference-center links appearing as the first text.
• Raw merge tags such as {{first_name}} or *|FNAME|* showing unrendered.
• An image alt string becoming the only available text when the body starts with a hero image.
• Empty whitespace from padded spacers leaking in so the preview shows as blank.

Each of these is the default behavior when you do not set a preheader. They are invisible to you in the editor because the editor shows the designed body, not the inbox snippet. They are the first thing your reader sees.

How Do You Implement a Hidden Preheader Div Correctly?

A hidden preheader is a block of text placed at the top of the body, visually hidden, that holds your intended snippet. The trick is hiding it without letting the next body line bleed in. If you simply set display:none, some clients (notably older Gmail) ignore it and revert to the first visible text. The robust pattern hides it with a combination of techniques.

Use a container with a small height, overflow hidden, and color matching the background, plus a long run of non-breaking spaces or a zero-width spacer after your text so the following content is pushed out of the snippet window. The goal is that the client's text extraction stops inside your controlled block instead of continuing into the body.

How Do You Set a Preheader in Mailchimp?

Mailchimp exposes a dedicated "Preview text" field in the campaign setup, separate from the subject line. Fill it there rather than relying on a hidden div, because Mailchimp injects the value as a hidden preheader for you. If you also have a hidden div in your template, remove it to avoid conflict. The field is the supported path and survives template changes.

How Do You Set a Preheader in HubSpot?

HubSpot lets you set preview text in the email editor under the subject line options, and it also supports a preheader module you can drop into the template. Use the built-in field first. If you are on a coded template, add a hidden preheader block at the top of the body as you would in raw HTML, and confirm HubSpot is not already injecting its own.

How Do You Set a Preheader in Klaviyo?

Klaviyo has a "Preview text" input in the message settings that overrides body extraction when filled. Leave it blank and Klaviyo falls back to the first body text, which restarts the failure modes above. For template-controlled control, you can also use a hidden preheader block, but the settings field is the simpler and more reliable option.

How Do You Set a Preheader in Raw HTML Templates?

In a raw HTML template, add the hidden preheader block as the first element inside the body, before your hero or content table. Pair your snippet text with a spacer of non-breaking spaces so the next line is pushed past the client's extraction limit. Test in Gmail and Apple Mail specifically, since their extraction rules differ most from each other.

Do ESP-Specific Preview Text Fields Override the Hidden Div?

Most modern ESPs inject a hidden preheader from their dedicated field at send time, which overrides body extraction. If you set both the field and a hidden div, you can get duplication or a conflict where the client picks one unpredictably. Pick one method per send: use the ESP field when it exists, and reserve the hidden div for raw or coded templates without a field.

How Does Apple Mail Privacy Protection Change How You Judge Preview Text?

Apple Mail Privacy Protection auto-loads remote images and triggers open pixels for many recipients, which inflates open rates. A preview text that looks like it is winning on opens may simply be benefiting from auto-opens. The signal that still means something is the click and reply rate, because those require a human to act.

Judge preview text by whether it moved clicks and replies, not by whether opens went up. If a curiosity-gap preview raises opens but drops click-to-open rate, it is baiting the auto-open, not the reader. Measure the downstream action the preview was meant to drive.

Which Preview Text Writing Patterns Actually Work?

• A curiosity gap the email pays off: promise the reveal inside, not in the preview.
• The specific offer detail the subject omitted, such as a date, number, or name.
• A personalization token with a safe fallback so empty fields do not leak.
• A plain summary for transactional mail, stating exactly what the email is about.

The pattern depends on email type. A welcome email can use a warm summary, while a cold outbound can use a specific, low-hype detail. The through-line is that the preview earns the open by adding information the subject did not, not by repeating it.

What Preview Text Patterns Work by Email Type?

How Do You a/B Test Preview Text Without Confounding the Subject Line?

To learn what preview text does, you must hold the subject line constant and vary only the preview. If you change both at once, you cannot tell which line moved the result. Most ESPs let you split on a single field; set the subject as a fixed value and randomize the preview across variants.

Keep the test valid by sending to a true random slice of the same list at the same time, with a large enough sample that the click-rate difference clears normal noise. Read the result on click and reply rate, not opens, given auto-open inflation. Only promote a variant once it wins on the action you care about, not on a vanity metric.

What Is the Write-And-QA Workflow Before You Send?

1. Write the preview as the second line of one inbox sentence, front-loaded within 35-50 characters.
2. Set it in the ESP field or a hidden preheader div, removing any conflicting method.
3. Add a zero-width spacer after the snippet so the next body line does not bleed in.
4. Render-test the send across Gmail, Apple Mail, Outlook, and a mobile client.
5. Check truncation at the 35-character mobile budget to confirm the core message survives.
6. Confirm merge fields have fallbacks so empty values never leak into the preview.
7. Verify the mobile-first preview reads complete before approving the send.

What Should the Pre-Send QA Checklist Cover?

• Render test across Gmail, Apple Mail, Outlook, and at least one mobile client.
• Truncation check at the smallest budget, roughly 35 characters on mobile.
• Fallback for empty merge fields so no raw tags or blanks appear.
• Mobile-first preview that reads as a complete thought when cut off.
• Confirmation that only one preview method is active, field or hidden div, not both.

Frequently Asked Questions

What Is the Difference Between Preview Text and a Subject Line?

The subject line is the headline you write in the subject field, while preview text is the snippet most clients show beside it, drawn from the body or a dedicated preheader. The subject sets the promise; the preview extends or pays it off. Keep them as one sentence rather than repeating the same words in both, which wastes the extra real estate you were given.

How Long Should Email Preview Text Be?

Write a front-loaded core of about 35-50 characters that survives mobile truncation, then add a longer tail of 40-90 characters as a desktop bonus. The smallest budgets, such as mobile Outlook near 35 characters, determine your core. The tail should be discardable, so truncation never lands mid-thought or drops the main message you intended the reader to see.

Why Does My Preview Text Show "View in Browser" Or "Unsubscribe"?

Those phrases are the first renderable text in your template, so the client extracts them as the preview by default. You fix it by placing a dedicated preheader element or setting the ESP preview field before that boilerplate appears. Removing the boilerplate from the top of the body, or hiding it behind a controlled preheader, stops the leak into the inbox snippet.

Can I Use a Personalization Token in Preview Text?

Yes, but always give it a safe fallback so an empty field does not leak a raw tag or a blank into the snippet. Write the token inside a phrase that reads fine without it, such as "Welcome back, [first_name or member]". That way the preview stays clean for recipients whose data is missing, and the personalization still shows for those who have it.

Does Preview Text Affect Email Deliverability?

Preview text itself is not a direct deliverability signal, but a broken preview full of boilerplate or raw tags hurts engagement, and low engagement over time can affect sender reputation. A clean, relevant preview improves open and click rates, which mailbox providers read as a positive signal. Treat it as part of the engagement equation rather than a separate technical setting.