---

Ok, so you’ve spent all that time crafting the perfect subject line. It’s short and sweet. It’s on-brand. It’s clever. Everyone has signed off on it. It even has… a blank square? [caption id="attachment_11244" align="alignnone" width="519"] Source : https://success.salesforce.com/answers?id=9063A000000aCtgQAE[/caption] It should have looked like this: Uh oh. What went wrong? 🧐 Anytime something breaks in an email, there are some implications that email marketers need to be aware of. Broken links can mean that the revenue or sales goals of a campaign could take a hit. Broken images lead to a disappointing experience for your subscribers. And rendering issues? Don’t even get me started! The cost of a broken email can be significant, but it also doesn’t do anything positive for a brand’s reputation, even if they send an apology email. That’s definitely something we don’t want to happen. So, what about when a subject line is broken? Personally, if I received an email with a subject line that looked off, I may think twice about opening it. It could be a spam or phishing attempt. Or, it could be a perfectly legitimate email with some rendering issues. Will your recipient take that chance? Or will they mark it as spam, and move to the next email bidding for attention in their inbox? You have about eight seconds for your subscriber to read your email (and complete the CTA, whether that’s clicking through to buy, donate, or learn more). There is plenty of competition vying for attention in the inbox, so it’s in our best interest to do some testing to see what could happen before including emojis in our subject lines.

How do emails work? 

First, let’s start with what's happening before we get into what went wrong. If we look at an email as a whole, it’s composed of two main parts: the message header and the message body. The message body contains the largest visible part of the email, all the lovely HTML that you’ve designed and coded. The message header is also important. Sometimes referred to as envelope information, the header contains the subject line, from and to addresses, preheader text, and other information about the email. Each of the two parts of the email has a different purpose, but couldn’t exist without the other. In an email client, the subject line is treated a little differently than the body. It is treated more like a text field than an HTML field. It cannot be styled with HTML tags like`<strong>` or `<em>`. But unlike in a plain text email, special characters (such as emojis, em-dashes, etc.) can be pasted in. [caption id="attachment_11247" align="alignnone" width="551"] Aa screenshot of an emoji in a subject line from Old Navy.[/caption] Cool, right? Emoji usage in email has exploded in recent years, and for good reason. They can help to break up lines of text and bring a brand’s personality to the inbox. Emojis may even help to increase open rates by drawing attention to the subject line. A/B testing subject lines with and without emojis to see which leads to better open rates, engagement, etc. is a use case that may apply to your brand marketing strategy.

What could go wrong? 

Things start to break down when we look at how special characters work in the subject line. Remember, the subject line is not an HTML field. While including a registration mark within a headline in the body of an email is as easy as `&reg;` that same character may render as a literal `&amp;reg;` in the subject line. Here’s an example: If you can’t use HTML entities to add a special character to a subject line or preheader text, what about using the character viewer (Control + Command + Space, if you are on a Mac) or character map on Windows? And what about copy and pasting? In my testing, copy and pasting, or inserting a character from the palette was more reliable than using HTML entities. However, there were still unexpected results. In one email client (Telstra), the registration mark and emoji did not render and put a space in its place. Inbox previews show all characters except `&amp;` rendering in Outlook 2010, yet once the email was sent, the registration mark rendered as `(R)` (a capital "R" surrounded by parenthesis). Of all the things that could happen, this isn’t terrible, but it is inconsistent. [caption id="attachment_11249" align="alignnone" width="533"] The preview shows that the registration mark should come through as the special character, not as an (R)[/caption] Just like AMP for email, fonts, GIFs, and other email enhancements, support for special characters in subject lines can be inconsistent.  It also can vary between email clients or ESPs. One more thing to keep in mind: special characters may trigger spam filters, corporate filters, or cause deliverability issues. Incorrectly coded emojis in subject lines can lead to an inconsistent (and possibly poor) user experience for your subscriber, customer, or potential donor. While we are all human and mistakes do happen, a broken subject line— which is the first peek a recipient gets of your email—could erode the trust that you’ve worked hard to establish. I am a firm believer in progressive enhancement when it comes to email design and development. Progressive enhancement, a term carried over from web development, involves designing core features for the largest possible audience. Then, additional features are added for users with more modern browsers or technologies. For emails, the progressive enhancement could look like this:

• Coding for the email clients in your audience—Outlook or Lotus notes, for example—that support less modern CSS. This may vary, depending on your audience.
• Adding features and styling—like hover effects or animated GIFs—for more modern email clients like Apple Mail.
• When using emojis in subject lines, you may want to segment your audience so that some receive a “safe” non-emoji version.

What can we do?

For best results, set the charset of your HTML file to `UTF-8`. This tells ESPs, servers and email clients how the characters in your email will be encoded. Character encoding is a link between the visual representation of a character (like a registration mark or em-dash) and the bytes that store them in memory. When a character hits a server or email client, if it's properly encoded, it renders. If it does not recognize the character, or if the encoding is missing, it will fail. You will likely see question marks (??), or blocks (▮ or ▯) instead of the character you specified.

What about emojis in the preheader?

Luckily, preheaders support emojis, even in an email client that does not render them correctly in the subject line. The preheader is part of the message body, which renders HTML like your <table> and <img>. Preheader text is usually an invisible section at the top of the email, that is read by email clients as the first 50 to 100 characters after the subject line in an inbox preview. For your preheader, include an emoji’s HTML entity, for example, `&#127828;` for the cheeseburger(🍔) emoji in your HTML tag. If preheader text is not specifically set, a recipient will see whatever the first 50-100 characters are after the opening <body> tag. Depending on how your email is set up, this could be your “view in browser” language, alt text, or in some cases <img> URLs or link tracking parameters.

Conclusion

Yes! Special characters can be used in subject lines. But, support across email clients—surprise—is inconsistent. Emojis in preheaders, on the other hand, are supported more consistently, even if the email client does not support emojis in the preheader. An emoji, for example, may render in color for an iPhone user and in black and white for an Outlook user. If the special character is not supported at all, your recipient may see something else entirely! Of course, I highly recommend testing the special characters you have in mind for the subject line and preheader (hey, test your whole email if you haven’t already) before sending them to your audience. And, if you are risk-aware, substituting special characters for more common ones (a double or single hyphen in place of an em-dash) is ok.