A few weeks ago my friend Rob told me he had registered a domain on my behalf.
It was π.prawnburrito.com.
Rob is a smart arse. He knows I write about infrastructure and the web, and he knows the eggplant emoji will make me sigh in a group chat. But once I stopped rolling my eyes, I realised it was a decent excuse to look at how emoji URLs actually work - and where they start to fall apart.
What Rob actually registered
prawnburrito.com is an ordinary .com. Under ICANN's IDNA 2008 rules, the second level of a generic TLD cannot contain emoji. The rules are laid out in RFC 5892, and ICANN's Security and Stability Advisory Committee has been warning about emoji in domain names since at least SAC095. So you cannot register something like π.com through a normal registrar.
What you can do is add an emoji to a subdomain if your DNS host lets you. Rob controls prawnburrito.com, so he created a DNS record for π.prawnburrito.com. The public name resolves as Punycode - xn--gi8h.prawnburrito.com - and currently points to Cloudflare's edge, where it serves my own blog, gavinj.net. I do not know whether that is a redirect, a CNAME, or just Rob poking me in the ribs from a thousand kilometres away.
Either way, it is real: type π.prawnburrito.com into a browser that understands it and you end up on a page with my name in the title.
How emoji domains work, briefly
The Domain Name System only speaks ASCII. To get Unicode characters into DNS, the Internationalized Domain Name system encodes them with Punycode. Any non-ASCII label is translated into an xn-- form before it is queried.
For example:
| What a human sees | What DNS sees |
|---|---|
π |
xn--gi8h |
The browser does the translation in the background. If it accepts the label, you see the emoji. If it does not, you see the Punycode, or nothing at all.
There is a small list of symbols that work without Punycode - the trademark, information and circled-M emojis - but almost every other emoji has to go through this conversion. That is why π.prawnburrito.com is really xn--gi8h.prawnburrito.com under the hood.
The security side: spoofing and trust
The obvious risk with any IDN is a homograph attack. A Cyrillic a looks identical to a Latin a, so apple.com and Π°pple.com can render the same way even though they point to different places. Browsers have spent years tightening which scripts can appear together in a single label to stop this.
Emoji raise the same trust problem in a louder, sillier package. A link that says π.legitbank.com in one app might expand to xn--gi8h.legitbank.com in another. Most users have no idea the two are the same address. Worse, some email clients and messaging apps will not hyperlink an emoji URL at all, so an attacker can hide the real destination behind pasted text that looks clickable.
It is not that emoji domains are inherently malicious. The issue is that they add a layer of indirection between what people read and what the machine resolves. Anything that widens that gap is useful to phishers.
ICANN's position is essentially: emoji do not belong in the stable, globally consistent part of the DNS hierarchy. That is why they are barred from new gTLDs and from the second level of .com. Subdomains are the wild west, which is how Rob got away with it.
The usability side: emoji was not made for typing
Even if you trust the domain, getting to it is harder than it looks.
- Typing. On a phone you can long-press the globe key and hunt for the eggplant. On a desktop you need an emoji picker, a compose sequence, or a copied character. It is faster to type
xn--gi8h.prawnburrito.com, which rather defeats the point. - Copy and paste. Behaviour varies between operating systems, browsers, and apps. Some paste the emoji. Some paste the Punycode. Some paste nothing useful at all.
- Email. Many mail clients will not auto-link an emoji URL. Recipients have to copy it manually, at which point the visual pun is more trouble than it is worth.
- Certificates. A TLS certificate issued for
prawnburrito.comwill coverπ.prawnburrito.comif it is a wildcard. A certificate issued for the Punycode label alone is valid too. The mismatch between what users see and what is cryptographically bound to the name is another small source of friction.
In short, emoji URLs work best when the URL is shown to you by someone else: a QR code, a poster, a social post, or a prank. They are not practical for anything you expect people to type from memory.
What I took away from it
Rob's subdomain is harmless. It is a joke that happens to sit on a real DNS record, and it is a neat demonstration that the internet will let you do things the standards bodies quietly wish you would not.
But the exercise also shows why the standards bodies said no. Emoji in domain names create a gap between appearance and identity. They make URLs harder to type, harder to verify, and easier to misuse. For a marketing campaign with a controlled audience they might be fun. For everyday navigation or security-critical links they are a bad idea dressed up as a cute one.
And yes - Rob is still a smart arse.