Notify me on Messenger
10 min

Update: Check out how easy it is to customize the preheader text in MailUp (version 8.8.3)

“View it in the browser” is not a good preheader

The preheader is the first line of machine-readable content that exists in your email, and it’s what most email clients show right next (or right below) the subject. Because of its placement in the inbox, it carries a lot of weight in a recipient’s decision to open the message or not, and should therefore be an enticing summary of what the email is about.

Here’s a Gmail inbox on a mobile device: the preheader is the text in light gray shown after the message subject.

Example of preheaders in Gmail

In this article we’ll look at what you can do to optimize the preheader, focusing mostly on mobile email clients.

On a mobile device – which is increasingly where email opens happen – speed-reading users glance at their inbox and click only on the messages that grab their attention.

Let’s get to the main issue right away:

  • A best practice in email design is to include a link to the Web version of the message at the top, so that, if the reader is having issues viewing the message, they can quickly reload it with their browser
  • That link, which typically says something like “Display problems? Click here” (or alike,) is definitely not what you want to display next to the subject, since it provides no information on what the message is about.

For example, take these two messages shown in the email client on an Android phone:

Email on mobile preheader

As you can see, the first message shows a much more descriptive preheader, cut off at around 45 characters (with spaces). In the case of the second message, instead, the email client found the “Please see the Web version…” link as the first machine-readable text, and therefore showed that specific copy, which does not help the reader learn more about the message.

Links or summary at the top? Two conflicting needs?

There seem to be two conflicting needs:

  • You need the message preview displayed by the email client (sender + subject + preheader) to be as effective as possible in order to drive the highest open rate.
  • You might very well need the first machine-readable text shown in the message to be something other than a great summary of the email. For example, the link to the browser version, or maybe navigation links to key areas of your Web site (e.g. an email sent by an ecommerce merchant), or perhaps an image (some email clients will put “[image]” in the preheader in that scenario).

What should you do then?

The solution: using a hidden preheader

Fortunately, a tiny bit of HTML code comes to the rescue, allowing you to add a preheader to the message that is hidden when the message is opened. The best of both worlds!

We spent some time testing out different variations of the code on a variety of Web, desktop, and mobile email clients, and we believe to have found a combination that works pretty much everywhere. So, let’s cut to the chase. Here we go:

<div style=”display: none !important; mso-hide:all;”>Lights on Spring Season 2013: we’re back to sharp contrasts</div>

Let’s look at it:

  • This is a DIV (i.e. a block of HTML)
  • There is a inline style attached to the DIV. Since it’s inline, we don’t have to worry about the email client not seeing styles located elsewhere (some don’t like that)
  • The style says to hide the DIV when the message is shown. Geek notes: the “important” declaration helps with Gmail, and the “mso-hide:all” one makes Outlook behave nicely.
  • The style is ignored by the email client when it searches for the first machine-readable line of text, which means that the text included in the DIV will be displayed.

This is the preheader that we used in our tests. You can see it – partially cut off – in the screenshot above. When the message is opened, though, the preheader is hidden correctly in all the mobile, desktop, and Web clients that we tested. Here is an example:

Preheader hidden when message opened


A customized text version as a fallback

In our tests, didn’t display the preheader included in the hidden DIV. No worries, though. likes to use the first line it finds in the TXT version of the message. This means that if you can edit the plain text version of the message and place a summary at the top, you are all set.

This is indeed something that you can do in MailUp 8.2.4 and above, where you can manually edit the plain text version of the message using a new tool that is part of the “Check Up” feature. In previous versions (or if you don’t manually edit the text version), the plain text version was created automatically from the HTML.

Note that only relying on the TXT version of the message is not enough. Gmail, for example, does not grab the preheader from it, but rather from the first machine-readable line in the HTML of the message.

Therefore, to have control of the message summary that will be displayed in as many email clients as possible, you need both:

  • The preheader in the message, which you can hide as mentioned above, if you wish
  • A quick summary line at the very top of the TXT version of the message

Not just in mobile devices

Although in this article we are focusing mostly on the importance and the display of the message preheader in mobile email clients, please note that the preheader is used in desktop and Web clients too, and it’s extremely important there as well. Here’s an example of the preheader shown in the message preview by the desktop version of Outlook 2010.

Preheader used by Outlook

Other notes on optimized preheaders

  • Email clients typically display the first few dozen characters (including spaces) in the pre-header. This depends on the email client, on the phone orientation, on the length of the subject (e.g. Gmail), etc. The point is that the juicy stuff should come first.
  • The preheader should always be consistent with the content of the message: never “trick” readers into opening a message by using a misleading preheader.
  • When you view the message in your email editor, the preheader DIV will likely not be shown. So, if you create a new message by making a copy of an old one, remember to change the preheader!

Happy emailing… and let us know if you encounter any issues with the HTML code we included above.

BTW: See an update on this topic >>

Liked this article? We have plenty more in store for you.

Subscribe to get news, tips and updates delivered to your inbox.

Read also

How to personalize your emails: dynamic fields, images and contents

In addition to segmentation and automation, there is a set of techniques and tools for sending messages in line with the characteristics of each contact. ...

Read more

4 Steps To More Relevant Email Profiling

A complete guide to developing an organic profiling cycle: from the collection of different data clusters (personal data relating to interests and behaviors) to segmentation, ...

Read more

How To Use Emojis In Email Subject Lines

From emojis for branding emails to those that are more evocative, we'll look at the potential of these small but effective graphic elements that can ...

Read more

5 Killer Ways To Boost Email Conversion Rates

From micro-conversions to the top requirements for an effective call to action, we explore the ins and outs of email marketing's most closely tracked, yet ...

Read more

Which Email Layout Is The Best?

How do you choose the best email layouts for your campaigns? Here are 3 steps to follow in order to cater to recipients' habits and ...

Read more

How TAG Innovation School increases enrollment in courses using Email Automation

We asked the platform for master's programs and courses to tell us how it managed to increase enrollment thanks to automatic email workflows.  What does automation ...

Read more
  • Hi Guys,

    I’ve had a huge problem with HTML displaying in my transactional emails in the preview pane on iOS7’s native email client.

    My first thought would be that adding in a preheader would work, and used your example above as a test and identified the following:
    – My HTML still showed in the preview (haven’t figured this out as of yet)

    – The inline styles aren’t hidding the text within the mail itself on iOS (though did work in all other clients I tested).

    May be worth making mention of this (and as soon as I find a solution, I’ll let you know).


    • mailupinc

      Hi Nick, thanks for the comment. We’ll do some more testing with iOS 7 and get back to you.