How to Write Email Preview Text That Supports the Subject

Email preview text is the short line that may appear beside or below the subject in an inbox. Write it as the subject's second line: let the subject identify the topic, let the preview add useful context or the next step, and let the opening of the message confirm the same idea. Before sending, check what happens when the custom preview is missing, when the line is truncated, and when the message is viewed on a different device or in a different client.

This guide covers the writing and review decision. It does not claim that Folderly controls an email client's preview, renders a live inbox, or predicts an open rate.

What should email preview text do?

Give the preview one clear job. It can add a detail, name the decision inside the message, or make the next step easier to understand. It should not repeat the subject word for word or introduce a claim that the body cannot support.

Use this division of labor:

Message part	Main job	Review question
Subject	Identify the topic or reason for the message	Would the label still be accurate if the message is searched later?
Preview text	Add context, a useful detail, or a next step	Does it contribute something new without overstating the message?
Opening body	Confirm the expectation and provide the needed context	Does the first useful sentence match the subject and preview?

For subject decisions, use the email subject-line guide or try the subject-line tool. The preview is a companion to that work, not a second subject line packed with extra claims.

Start with the fallback case

Some sending platforms provide a dedicated preview or preheader field. If you leave it empty, an inbox may pull the first text from the message instead. Mailchimp describes this fallback behavior and notes that the visible amount varies by email client in its preview text guidance. Campaign Monitor gives similar guidance in its preheader text documentation.

That makes the beginning of the body part of the review. Check that it does not start with an unhelpful label, a “view in browser” line, a navigation fragment, or a sentence that only makes sense after several paragraphs. If a custom preview fails to appear, the opening should still make a reasonable first impression.

Do not try to hide a long keyword list or a second message in the fallback. A reader should get the same honest context whether the custom field appears or the client uses the start of the body.

Make the subject and preview complement each other

Read the two lines together before reading the body. If they repeat one another, use the preview for the missing piece: a decision, an included detail, or a practical next step.

These examples are hypothetical writing exercises. They do not describe a customer, campaign, measured result, or Folderly capability.

Subject	Preview text	Why the pair is useful
Review the Q4 onboarding email	Three questions to settle before the copy review.	The subject names the task; the preview tells the reader what the review contains.
Draft options for the launch note	Compare the two openings before choosing one.	The subject names the asset; the preview describes the immediate decision.
A question about your handoff	A short context note is included below the question.	The subject stays neutral; the preview sets an expectation without claiming private knowledge.

The pair becomes misleading when the preview adds urgency, a result, or knowledge that the sender cannot support. “Your team is losing leads” is not a safe addition just because it may attract attention. Replace it with a specific, verifiable purpose or a transparent question.

Do not use one universal character rule

The field you can author and the text a recipient can see are different things. Campaign Monitor currently documents a preheader field of up to 150 characters while also noting that clients can show much less. That provider-specific limit is useful when configuring that platform; it is not a standard amount of visible space across inboxes.

Review the beginning, middle, and end of the line:

• Put the essential context first because later words may be cut off.
• Avoid ending the visible part with a fragment that changes the meaning.
• Keep the preview understandable if a narrow screen shows only the opening phrase.
• Remove filler that does not help the subject, decision, or next step.
• Recheck punctuation when the line is shortened by the client.

Shorter is not automatically better. A five-word preview that repeats the subject is less useful than a slightly longer line that adds the one detail a recipient needs to decide whether to read now.

Use a fallback and truncation review matrix

Before sending, record what you know and what remains client-dependent. This keeps a preview review from becoming an unsupported rendering claim.

Check	Sender-controlled question	Client-dependent boundary
Custom field	Did the sending platform save the intended preview text?	The inbox may omit, alter, or replace it.
Fallback	Does the first body text work if the field is empty?	The client decides which body text it extracts.
Truncation	Does the first phrase carry the important meaning?	Width, font, device, and client affect the visible amount.
Mobile view	Is the pair understandable on a narrow screen?	The exact line break and visible length vary.
Dynamic content	Are merge fields and conditional phrases safe when resolved?	A test preview may not represent every recipient value.
Body alignment	Does the opening confirm the two inbox lines?	Images, remote content, and client handling can change presentation.

The matrix separates a review you can perform from a display you cannot control. Mark an unknown as unknown and test the sending path that will actually be used.

How should you test preview text before sending?

Use the preview and test tools in the sending platform, then send a controlled test to the relevant accounts or devices when that is appropriate. Mailchimp's preview and test guidance explains that HTML email can display differently across clients and that dynamic merge tags in a test may not represent the final recipient data.

Run the review in this order:

1. Read the subject, preview, and first body sentence as one unit.
2. Remove the custom preview and inspect the fallback opening.
3. Check the preview in the platform's desktop and mobile views.
4. Test representative recipient data when the message contains personalization or conditional content.
5. Inspect the final send path and record which client, device, and test data were used.
6. Correct any mismatch before approving the message.

The result is evidence about the selected platform and test conditions. It is not proof that every recipient will see the same line.

What preview text cannot tell you

Preview text can improve clarity before a reader opens a message, but it cannot establish inbox placement, recipient intent, or a future open rate. Opens are affected by delivery, client behavior, privacy settings, audience fit, timing, and the message itself. A polished preview should therefore be treated as copy quality work, not as a performance promise.

It also cannot replace sender and compliance checks. Use the email deliverability test for its documented pre-send review scope, and keep claims, recipients, permissions, and suppression decisions with the appropriate owner.

A compact pre-send checklist

• The subject identifies the real topic.
• The preview adds context instead of repeating the subject.
• The first body text works as a fallback.
• The most important meaning appears early enough to survive truncation.
• Hypothetical or conditional language is clearly supported by the body.
• Merge fields and conditional text were checked with representative data.
• Desktop and mobile previews were reviewed in the sending platform.
• The review record names its client, device, test data, and remaining unknowns.
• No line promises an open rate, inbox placement, or result that the evidence cannot support.

Sources and maintenance

• Mailchimp: About preview text — preview placement, body fallback when custom text is absent, and client-dependent visible length. Checked 13 October 2026.
• Campaign Monitor: Preheader text — preheader authoring, a provider-specific field limit, fallback behavior, and client variation. Checked 13 October 2026.
• Mailchimp: Preview and test your email campaign — client rendering differences, preview/testing, and limits of dynamic merge-tag tests. Checked 13 October 2026.

Use the subject-line tool to draft alternatives, then review the preview line in the sending platform that will deliver the message. Folderly can help with the writing workflow and documented pre-send checks; it does not control or certify how a recipient's inbox will render the preview.