Email Preheader & Preview Text: HTML Code and Examples

Where the preview text comes from

Email clients take the preview from the first text in the body. Gmail calls it a snippet, Apple Mail a preview, Outlook a message preview. There is no header or meta tag for it: whatever text comes first in <body> wins.

In most templates that is not the message. It is a view-in-browser link, the navigation, the alt text of the logo, and occasionally an image URL. The preheader is a sentence you put in front of all of that, so the client picks it up instead. Most sending services have a preheader field that does this for you; use it, or code it yourself, but not both, or you end up with two blocks and only the first one counts.

The hidden preheader HTML

The usual pattern is a div placed first in <body>, hidden so it shows in the inbox but not in the opened email:

<body style="margin:0; padding:0;">
  <!-- Preheader: the first thing in <body> -->
  <div style="display:none; max-height:0; max-width:0; overflow:hidden;
              mso-hide:all; opacity:0; color:#ffffff;
              font-size:1px; line-height:1px;">
    Your order ships Tuesday. Change the address until Monday 6pm.
    &#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;
  </div>

  <!-- the rest of the email: view-in-browser link, logo, content -->
</body>

The hiding is done several times over, because no single property works everywhere:

• display:none does most of the work. Can I email lists it as supported almost everywhere, with partial support in Outlook for Windows: it does not inherit onto nested tables.
• mso-hide:all is Outlook's own hide property, the belt to display:none's braces in the Word-based desktop versions. The other mso- properties are covered in coding templates for Outlook.
• max-height:0, max-width:0, overflow:hidden collapse the box in a client that drops display:none.
• opacity:0, a color that matches the background, font-size:1px, line-height:1px are the last line: if everything else fails, the text is tiny and invisible. Change #ffffff to your body background.

Email on Acid's version of the block adds visibility:hidden as well, and says outright that most of these properties are fallbacks for clients that ignore the others. MJML generates nearly the same set, shown below.

The spacer that stops body text leaking in

A client fills the whole preview line. If your preheader is shorter than the space, it carries on into whatever comes next, and “View in browser” is back. The fix, popularised by Litmus, is to pad the preheader with characters that take up room but print nothing.

The original version repeats ‌  (a zero-width non-joiner and a non-breaking space), often with ͏, the combining grapheme joiner. Litmus reports that it stopped working in Yahoo Mail, and its June 2023 update adds Mark Robbins' suggestion of   (a figure space) and ­ (a soft hyphen), which still hold space in Yahoo and iOS 16.4. That is the group repeated in the snippet above:

͏‌  ­

Three caveats keep it honest:

• It is a progressive enhancement. Litmus notes that since March 2023 the hack does not work in every case, and that clients change. Test it rather than trusting it.
• Listeners hear the preview. The hiding styles keep the block from screen readers inside the email, but Siri reads the sender, the subject and the preview, and Dotdigital says that when the preview is short it carries on into the HTML. A real sentence first, then the spacer, is what a listener should get. The rest of the subject belongs to the email accessibility guide.
• Keep it short. Repeat the group until your tests stop showing leaked text, then stop. Every entity is bytes in the HTML, and they count towards Gmail's 102KB clip.

The block also needs to stay out of the text version: the plain-text part should not open with the preheader and a run of invisible characters.

How long it should be

There is no single length, because each client shows a different amount and readers can change it. Litmus says, depending on settings, someone may see anywhere from five lines (about 278 characters) to none, and recommends staying under 90 characters. The React Email docs give the same 90. Email on Acid puts what many mobile devices show at 35 to 50 characters, says some desktop and webmail clients show more than 100, and notes that webmail varies with the length of the subject and the width of the window.

The practical rule: say the point in the first 35 characters or so, keep the whole sentence under 90, then pad with the spacer. The subject line and preheader tester shows where Gmail, Apple Mail on iPhone, Outlook, Yahoo and Samsung Email cut both lines as you type.

What to write

Read the subject and the preheader as one line, because that is how they appear.

• Add, don't repeat. If the subject is “Your order has shipped”, the preheader is “Arrives Thursday. Track it or change the address”, not “Your order is on its way”.
• Lead with what matters. The end of the sentence is the part that gets cut.
• Match the email. A preheader that promises something the body does not deliver costs the next open.
• Give the next step when it fits. A date, a code, an action: whatever saves the reader a click.

Preview text examples

Each pair below reads as one line in the inbox. The preview text answers the question the subject raises, or hands over the thing the reader opened the email for.

The weak version of each repeats the subject (“Reset your password” / “Click here to reset your password”) and spends the only extra line the inbox gives you.

The same in React Email and MJML

React Email has a <Preview> component. Put it at the top of <Body> so it renders as the first text:

import { Body, Html, Preview } from "react-email";

export default function OrderShipped() {
  return (
    <Html>
      <Body>
        <Preview>
          Your order ships Tuesday. Change the address until Monday 6pm.
        </Preview>
        {/* the rest of the email */}
      </Body>
    </Html>
  );
}

It renders a hidden div and adds its own spacer, a run of non-breaking and zero-width characters, so you only write the sentence. It also cuts the text at a fixed length: 200 characters in react-email 6.9, 150 in the older standalone @react-email/preview package, which is what @react-email/components re-exports. Its block is marked to be skipped when React Email renders the plain-text version.

MJML has <mj-preview>, which goes in <mj-head> and takes no attributes:

<mjml>
  <mj-head>
    <mj-preview>
      Your order ships Tuesday. Change the address until Monday 6pm.
      &#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;&#847;&zwnj;&nbsp;&#8199;&shy;
    </mj-preview>
  </mj-head>
  <mj-body>
    <!-- sections -->
  </mj-body>
</mjml>

MJML 5 outputs it as the first element in <body>, hidden with display:none, max-height:0px, opacity:0 and the rest, but adds no spacer: add the entities yourself, as above. They pass through to the HTML unchanged. More on both frameworks in the React Email guide and the MJML guide.

Testing the preview

The preview only exists in an inbox list, so check it there: send to real accounts in Gmail, Outlook, Apple Mail and Yahoo, and look at the list before opening anything. You are checking three things: the sentence appears, nothing from the body follows it, and the spacer does not show as stray characters. If it does, look at the HTML your sending service actually sent; editors sometimes rewrite or drop entities.

The preheader is one line of the pre-send checklist in how to test HTML emails, which covers the rest of the workflow.