Become an email & SMS marketing pro

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

Notify me on Messenger
10 min
  • 1

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 Outlook.com 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 Outlook.com 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, Outlook.com didn’t display the preheader included in the hidden DIV. No worries, though. Outlook.com 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

7 Fresh Design Ideas for Your New Year’s Email Marketing

‘Tis the season of sending holiday emails! From last-minute sales and promotions to warm greetings and thank yous, we know you’re hard at work this ...

Read more

How To Build An Effective Welcome Series

Automated welcome workflows are the best way to start the relationship with news users on the right foot. Here is a hands-on tutorial and 4 ...

Read more

6+6 Ways to Create a Holiday Gift Guide for Email

One of the biggest challenges for those involved in marketing is to be able to generate demand for the products they're offering. In other words, ...

Read more

Bring your emails to life with video, animated GIFs, countdowns and dynamic images

How-to, pros and cons: why and how to give a dynamic boost to messages in order to increase opens and conversions.  According to a recent Cisco ...

Read more

8 Promotional Emails That Actually Work

How to ensure that your promotional emails nail the task they're set out to do - boost conversions? Here are 5 tips to keep in ...

Read more

Black Friday: an Email Marketing Strategy in 8 Steps

The key to making the most of 24 November (and the long legacy that lingers on until Cyber ​​Monday) is to prepare in good time, ...

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).

    Thanks
    Nick

    • mailupinc

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