Emoji in Email: Subject Lines, HTML and What Breaks

Emoji in the subject line: the header is encoded

A message header is ASCII. RFC 2047 is how non-ASCII text gets in anyway: the text is wrapped in an encoded-word, =?charset?encoding?encoded-text?=, and the client decodes it for display. The charset for emoji is UTF-8. The encoding is B, which is Base64, or Q, which is close to quoted-printable: each byte that is not plain ASCII becomes = and two hex digits, and an underscore stands for a space.

Subject: =?UTF-8?B?WW91ciBvcmRlciBoYXMgc2hpcHBlZCDwn5Om?=

Subject: =?UTF-8?Q?Your_order_has_shipped_=F0=9F=93=A6?=

Both decode to "Your order has shipped 📦".
  UTF-8          the charset of the bytes inside
  B / Q          Base64, or quoted-printable with _ for a space
  =F0=9F=93=A6   the four UTF-8 bytes of U+1F4E6 (package)

Three rules from the RFC matter when you write these by hand. An encoded-word may be at most 75 characters, so a long subject is split into several, separated by a folded line. Each one must hold whole characters: the four bytes of an emoji may not be split across two encoded-words. And the white space between two adjacent encoded-words is ignored on display, so the split does not add spaces to the subject.

You rarely write them by hand. Sending services and mail libraries encode the subject for you when it contains non-ASCII text; the hand-built case is a raw message assembled with string concatenation, which is where the mojibake comes from. RFC 6532 does allow raw UTF-8 in header values, but only when every hop supports the SMTPUTF8 extension, so an encoded-word is the form that works everywhere.

Emailens's inbox preview flags an emoji in the subject as an info note, not an error: it is allowed, it just looks different per inbox. How long the subject and preheader can be before they are cut belongs to the subject line tester and the preheader guide; whether your wording looks like spam, to the spam checker and what a SpamAssassin score means.

Emoji in the HTML body: declare UTF-8 twice

The body needs the charset said in two places. The MIME part carries it in its header, Content-Type: text/html; charset=UTF-8; without the parameter, RFC 2046 says a text part is US-ASCII. The HTML carries it in <meta charset="utf-8">, which has to sit in the first 1024 bytes of the document. Most sending services set the first; the second is yours, and it keeps a browser view of the same file honest.

Content-Type: text/html; charset=UTF-8

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Your order has shipped</title>
</head>
<body>
  <!-- The character itself: fine once the file is saved as UTF-8 -->
  <p>Your order has shipped 📦</p>

  <!-- The same emoji as a numeric reference: plain ASCII, survives re-encoding -->
  <p>Your order has shipped &#x1F4E6;</p>

  <!-- U+2764 with U+FE0F asks for the colour emoji, not the text heart -->
  <p>Thanks for being with us &#x2764;&#xFE0F;</p>
</body>
</html>

The character and the numeric reference end up the same. The reference, 📦, is plain ASCII, so it survives an editor, a template engine or a database column that quietly saved the file in another encoding. Some emoji, such as the heart, also exist as a text symbol; following them with U+FE0F, the emoji presentation selector, asks for the colour emoji rather than the black-and-white one, though Unicode notes the result can still vary by platform.

Why the same emoji looks different in each inbox

Your email sends a code point, not a picture. The recipient's system draws it, and Unicode has no say in which emoji a platform supports or what they look like: each vendor ships its own designs.

Some clients swap in their own images. Emojipedia documented in 2021 that Gmail on the web overlaid images of Google's emoji on the code points instead of using the system font, and that sequences mixing old and new emoji broke into their parts there, until Google announced updated emoji support from July 2021. In 2017 Email on Acid caught Gmail for iOS turning ©, ® and ™ into blue emoji images; Gmail fixed it two days later. The lesson is not the specific bug, it is that the client, not you, decides how the character is drawn.

Outlook is the question people ask most. A correctly encoded subject decodes there like anywhere else; how a given Outlook draws the glyph depends on the fonts of the system it runs on, and we found no Microsoft documentation that settles it. That is a question for a real preview, which is what testing an HTML email covers.

New emoji on old systems: boxes and split sequences

Unicode adds emoji in a new version roughly every year, and platforms ship them on their own schedule. A system with no font for a character shows a missing-glyph indicator, the empty box often called tofu. Many newer emoji are not single characters but sequences joined by a zero-width joiner; when a system does not support the sequence, UTS #51 says the joiners are ignored and the parts are shown as separate emoji. A family can arrive as four people in a row.

The safe choice for a subject line is an emoji that has been around for years, as a single character. Keep the newest ones for places where a box would not hurt.

Emoji or image for icons?

An emoji costs nothing to load and scales with the text, but it looks different in every inbox and can turn into a box. An image looks the same everywhere it loads, and Litmus recommends it over an emoji for exactly that reason when the icon carries meaning. Use an emoji where any design of it will do; use an image where the icon has to match your brand or where a box would break the sentence.

If you use an image, its alt text is shown when the image does not load, so keep it plain words rather than another emoji. Screen readers read an emoji out by its name, so a row of them becomes a row of names; the email accessibility guide covers how to label or hide them. If the emoji sits in a styled heading, how fonts fall back in email is in the email fonts guide.