Email Preheader Text: What It Is, Best Length and How to Write and Code It

In most inboxes, a message is shown as a row with three pieces of text: the sender name, the subject line and a short grey snippet of the opening text. That snippet is the preheader, also called preview text. The reader sees it before opening and it often decides whether the message is opened at all, yet many senders leave it to chance, so that the inbox shows "View this email in your browser" or the alt text of a logo. This guide explains how preheaders are chosen by mail clients, how long they should be, how to write one that works with the subject line, how to set it in HTML without showing it in the body and how to avoid the usual errors. It also notes that you can overdo it: a preheader is part of the message and should be honest and useful.

Where preheaders appear

Gmail, Apple Mail, Outlook, Yahoo and most mobile clients show a preview after the subject. The amount depends on the client, the device and the width of the window. On a phone it can be as few as 35 to 50 characters; in a wide desktop window, 100 or more. Some clients show nothing on certain layouts. Since you cannot know which, put the most important words at the start and write for the shortest view, then let longer displays reveal the rest. A common planning rule is: subject 30 to 50 characters, preheader 40 to 90.

How clients pick the text

Mail clients do not read a special field. They take the first readable text in the HTML body, skipping markup, and show as much as fits. If your template begins with a header image and navigation links, the preview shows the alt text and the link labels. If it begins with a hidden block, the preview shows that text. A plain-text part is used by clients that prefer plain text. So the way to control the preheader is to place deliberate text first, and to make sure that your plain-text version begins in the same manner. Read about the structure in HTML email templates.

Writing a preheader that works

1. Complement the subject. If the subject asks a question, the preheader answers part of it. If the subject names the offer, the preheader gives the condition or the deadline.
2. Do not repeat the subject. Repeating wastes the one extra line of attention you have.
3. Front-load. Put the strongest words first, since the display may cut the end.
4. Be specific. "Your invoice for October is ready, due 15 November" is better than "Click here to see more".
5. Match the content. A preheader that promises something the email does not deliver causes disappointment and complaints.
6. Use plain language. Avoid shouting words and excessive punctuation; see spam trigger words.
7. Test the pair. Read subject and preheader together as one sentence on a phone-width screen.

Examples

For more subject line ideas see writing subject lines, and for transactional messages transactional email templates.

Setting the preheader in HTML

Put a block at the top of the body that contains the preheader and is hidden from the visible message. The widely used pattern is:

<body>
  <div style="display:none;font-size:1px;line-height:1px;max-height:0;max-width:0;opacity:0;overflow:hidden;mso-hide:all;">
    Authentication, list hygiene and timing, in a five-minute read
    &#847;&zwnj;&nbsp;&#847;&zwnj;&nbsp;&#847;&zwnj;&nbsp;&#847;&zwnj;&nbsp;&#847;&zwnj;&nbsp;
  </div>
  <!-- visible header and content follow -->
</body>

The inline styles hide the block in browsers and Outlook (mso-hide:all). The string of entities after the text is a padding trick: it fills the rest of the preview with invisible characters so that the client does not append body text after your preheader. Without padding, a short preheader is followed by whatever text comes next, for example the first headline, which can read oddly. Keep the padding short and test, because clients differ in how they treat these characters. Do not use a transparent colour or tiny font alone to hide text; that is the pattern spam filters treat as hidden content. A short preheader that is a real sentence in a real hidden preview block is accepted practice and is not abuse.

Accessibility and plain text

Screen readers read the hidden preheader unless you hide it with aria-hidden, but since it is the preview text the reader would also hear in the inbox list, reading it again in the body is confusing. Many designers add aria-hidden="true" to the block, and keep the content of the preheader short and meaningful. In the plain-text alternative, begin with the same sentence so that both versions preview alike. See accessible HTML email.

Mistakes to avoid

• Leaving it empty and showing "View in browser" or navigation text.
• Repeating the subject word for word.
• Using a long preheader of 200 characters; the end is cut and the value is lost.
• Putting personal data or sensitive details in the preheader. Previews appear on lock screens and in notifications; do not show codes or account balances there.
• Making a promise the email does not keep.
• Forgetting to change it when you reuse a template, so that last month's preheader appears on this month's message.
• Relying on invisible padding that breaks in some clients without testing.

Personalisation and automation

Preheaders can use the same merge fields as the subject line, such as a first name or an order number, but give them a fallback so that a missing value does not leave a gap or a stray placeholder. In automated flows, write a separate preheader for each step instead of reusing one; a welcome series whose three messages show the same preview looks mechanical. If you send in several languages, write the preheader natively for each one, because a literal translation often exceeds the length that fits on a phone.

Testing

Send test messages to accounts at the providers your audience uses, on desktop and phone, and check the preview as the reader sees it. Many preview tools show approximate renderings, but real devices settle disputes. Run your message through the spam checker to make sure that the hidden block does not raise a flag. Record the open and click results of tests that change only the preheader; this is a good topic for A/B testing, as long as you test one change at a time.

The preheader is a few words with a large job. Write it on purpose, place it first, keep it honest and test it on a phone. Teams that do this reliably see better engagement than those that leave the choice to the mail client.

References and further reading

• Litmus: Email preheader guide
• Campaign Monitor: Preheader text
• W3C WAI: aria-hidden