We’re happy to offer emoji addresses that you can use for both email and web stuff. Emoji are fun and cool, but they can pose some technical challenges in different contexts. You should understand these issues before purchasing an emoji address on OMG.LOL.
Emoji are part of a more complex (“multibyte”) character set than ordinary letters and numbers. Email and web technologies were built during a time when emoji didn’t exist, so support for emoji in both can be inconsistent (ranging from “quirky” to “downright busted” depending on different factors).
First, the good news: in general, emoji work pretty well on the web. For example, the address 🍋.omg.lol will work in just about any modern web browser. But details around the behavior will differ between browsers. Safari will show the emoji in the address bar (i.e.
🍋.omg.lol), but Chrome shows
xn--li8h.omg.lol. The gibberish you see in the URL is known as Punycode, which is a standard that converts special characters (like emoji, accented letters, or diacritics) into a plain text representation that can play nicely with older tech. Both
xn--li8h.omg.lol are functionally identical; one is just much sexier than the other.
Email is where things become a bit bumpier. Support for emoji and other special characters is spotty across many of the underlying tech, and different implementations of that tech handle emoji support differently.
Let’s say you send an email to
🍋@omg.lol. It might actually go through, but more than likely one of these two things will happen:
Mail client issue
If your mail client doesn’t handle emoji correctly (and many don’t), here’s what can happen when the email hits the destination server:
Jan 1 23:59:59 server postfix/srvc: ABCDEF0123: from=<sender@domain>, size=1234, nrcpt=1 (queue active) Jan 1 23:59:59 server postfix/srvc: ABCDEF0123: to=<=?utf-8?B?8J+kqQfirstname.lastname@example.org>
In this case, the message is received, but the address is no longer intact, and the server doesn’t know what to do with it (so it won’t be delivered).
Mail server issue
If the email winds up going to a downstream destination server that doesn’t know how to deal with emoji, here’s what can happen:
Jan 1 23:59:59 server postfix/srvc: ABCDEF0123: from=<sender@domain>, size=1234, nrcpt=1 (queue active) Jan 1 23:59:59 server postfix/srvc: ABCDEF0123: to=<forwarded@destination>, orig_to=<🍋@omg.lol>, status=bounced (SMTPUTF8 is required, but was not offered by host mailserver[203.0.113.42])
Here we can see that the emoji address survived intact when the message reached OMG.LOL, but the server to which the message was forwarded didn’t have support for emoji addresses and the email wasn’t delivered.
What to do?
There’s no way to guarantee how things will behave when using emoji in email or web addresses, so this is a classic case of buyer beware. When you register an emoji address, though, you’ll also receive the corresponding Punycode namespace for both email and web (and this will appear in the address configuration for your reference).
This article was last updated 6 months ago.
We’d love your feedback on this article!