We need to talk about Emoji

Emoji is great, but it’s a big problem on the web.

I use emoji to, like, express myself, or whatever. I use it in tweets. Here’s a screenshot of a tweet, with emoji, running in an iOS simulator. iOS has native emoji support.

emoji in a tweet in an iOS simulator

Here’s that same tweet in Safari, running on Mountain Lion, which has native emoji support.

emoji in a tweet in Safari on Mountain Lion

Here’s that same tweet in Google Chrome, in the same operating system.

the lack of emoji in a tweet in Google Chrome on Mountain Lion

Oh no! Where’s the emoji? 😰1

Emoji is a wonderful method of expression. In this post, I’m going to propose a solution so that emoji can be displayed universally on the web. But it’s going to be a bit of work for the web application developer.

First, some background.

Emoji has been a hard target to support, because it has historically occupied a private use area of Unicode. And, depending on the implementor, be it Apple or DoCoMo or whoever else is really into to the emoji game, the ranges are always different. But now, Apple and Google have come together to formalize Emoji Symbols (warning: this is a very big page). If you look at the Character Viewer in Mountain Lion, you’ll see that the proposed emoji spec is totally implemented. What this means is that we can target specific unicode characters for being emoji.

Meanwhile, on the web…

GitHub introduced emoji pngs throughout their application, and pull requests are much better for it. Campfire supports emoji, and your professional interactions are much better for it. Both GitHub, Campfire, and others support a simple set of codes to inject these pngs into an html page. In fact, those codes have become a bit of a standard on their own. http://www.emoji-cheat-sheet.com/ has emerged to guide users and has almost formalized how these codes should work.

It’s somewhat trivial to implement these friendly codes and images on a web app that does any kind of text formatting (and all web apps should be at the very least sanitizing input). But what if my system supports emoji natively?

A Modest Proposal

I propose that on systems that natively support emoji, instead of showing the user an image, we show them the correct emoji character. On systems that natively support emoji, when the user inputs an emoji character (i.e. from their iPhone keyboard), the web application should recognize that unicode character, and replace it with the friendly cheat-sheet code.

Do not store emoji unicodes in your database. Store the human-friendly code and support the emoji-cheat-sheet.

By doing this, you can ensure that users across devices can see the author’s intention. You can always show users an image, but you can’t show them a range of characters their system does not support.

A solution in Ruby

I’m not going to stand on an ivory tower 🗻 and propose something without offering some kind of solution.

I made a Ruby gem to transcode emoji utf-8 into their cheat-sheet counterparts! Check out Rumoji.

gem install rumoji

Here’s a screenshot in action (for the emoji-disabled):

What's happening here is, we're piping some emoji in one end, and in the other end we're getting :joy:

Note: Rumoji only works in Ruby 1.9 and has only been tested on ruby v1.9.3. Currently, Rumoji is aware of the People range of characters in the emoji-cheat-sheet.

Use this in conjunction with a tool like gemoji to support transforming raw emoji input into images that everyone can enjoy.

Now go forth, web application developers. Let’s bring the beauty of emoji to everyone, regardless of their device!


  1. If you’re following along, there’s actually an emoji right now. Depending on your system, you might not be able to see it. It’s face with open mouth and cold sweat: cold sweat↩

  1. inky said: :thumbsup:
  2. mwunsch posted this