The evolution of emoji: from 176 pictograms to a composable writing system

In February 1999, NTT DoCoMo launched i-mode, and a message on it could carry 250 Japanese characters. Not 250 bytes of slack — 250 characters total, on a screen a couple of centimeters across, for everything from a weather report to "I'm running late." Shigetaka Kurita, then in his twenties on the i-mode team, had to make that budget carry tone and context as well as words. His answer was 176 pictograms drawn on a 12x12 pixel grid: a sun for fair weather, a heart, a phone, a train. One glyph, one character of the budget.

The motivation Kurita has described repeatedly wasn't aesthetic. DoCoMo's Pocket Bell pagers had included a heart symbol; a later model dropped it in favor of kanji and Latin characters, and teenage users walked to the competition. A picture was doing work that words were not. The original 176 are now in the Museum of Modern Art's collection, which is a strange fate for a compression hack.

The fragmentation problem nobody outside Japan noticed

Kurita's set was a carrier feature, not a standard. DoCoMo stuffed its pictograms into an extension of Shift-JIS. So did au by KDDI. So did J-Phone — later SoftBank — which had actually beaten everyone to it, shipping 90 emoji on the SkyWalker DP-211SW in 1997 on a handset almost nobody bought.

Three carriers, three sets, three different code positions for the same idea. Sending across carriers meant a gateway rewriting bytes through a lookup table on the way. When the table had no entry, your sun arrived as something else, or as a black box. This was not a theoretical interop concern; it was a daily "why did she send me a hammer" problem for tens of millions of people.

Google engineers started petitioning the Unicode Technical Committee about it in August 2007, framing emoji as an encoding-interop problem rather than a novelty. Apple joined, and a joint proposal for 625 characters went to the UTC in January 2009. Unicode 6.0 landed in October 2010 with 722 emoji encoded.

The receipt for the fragmentation era still ships in the Unicode Character Database. EmojiSources.txt maps each Unicode code point to its DoCoMo, KDDI and SoftBank Shift-JIS codes, round-trip, and its header reads: "Created for Unicode 6.0 by Markus Scherer. No mappings have been changed or added since then. No mapping changes or additions are anticipated." A file that was born closed.

A timeline of what actually changed

Version history is where most emoji articles wave vaguely at "then Unicode standardized it." The specific years matter, because what changed in each one is different in kind:

That last row is the whole modern story. Emoji 17.0 specifies 3,953 emoji using 1,438 characters. The gap between those two numbers is where emoji stopped being a list and became a grammar.

Modern emoji growth is sequences, not characters

Skin tone was the turning point. Unicode 8.0 didn't encode five versions of every human emoji — it encoded five modifiers and defined the combination as a sequence. A medium-skin-tone thumbs up is U+1F44D followed by U+1F3FD. Two code points, one glyph. The same trick, applied with a zero-width joiner (U+200D), gets you 👩‍💻 from a woman plus a laptop, and with a variation selector (U+FE0F) it gets you the difference between the monochrome dingbat ❤ and the red heart ❤️.

Elegant standards design. Also the reason your string handling is wrong:

const s = "👍🏽";

s.length                                     // 4 — UTF-16 code units
[...s].length                                // 2 — code points: U+1F44D U+1F3FD
[...new Intl.Segmenter().segment(s)].length  // 1 — what a human sees
new TextEncoder().encode(s).length           // 8 — UTF-8 bytes

s.slice(0, 2)                                // "👍" — skin tone silently gone

That slice is the bug you will actually ship. A 140-character preview truncated by code unit doesn't just cut text off; it can strip a modifier and change what the message says about a person, or leave a dangling joiner that renders as two glyphs where the sender wrote one. Old software that predates a sequence does the same thing on render — you have seen a thumbs-up followed by a lone brown square, and that is exactly what it was. If you want to see the actual code points behind a glyph before you write validation against it, an emoji picker lists every one in a sequence rather than just the first. The byte-level version of this problem — why the column that stores it also lies — is in UTF-8 and Unicode: why that emoji broke your database.

Why the same code point looks different on every phone

Unicode standardizes a character, a code point and a name. It does not standardize the picture. UTS #51 offers design guidance, and then Apple, Google, Microsoft, Samsung and every other vendor draws its own font. Same character, different art, and art carries connotation.

There is real research on the cost. In 2016, Miller et al. at the University of Minnesota's GroupLens lab had participants rate emoji renderings from five platforms for sentiment and meaning. Only 4.5% of the renderings they tested drew consistently low-variance sentiment ratings. In 25% of cases where two participants rated the exact same image, they disagreed on whether it was positive, neutral or negative — before any cross-platform mismatch enters the picture.

The headline case was U+1F601, "grinning face with smiling eyes." Participants shown Google's rendering described it as "blissfully happy." Shown the same Unicode character rendered in Apple's font of the day, they described it as "ready to fight."

Apple's version at the time was a tight-eyed grimace rather than a grin, and the Apple-versus-everyone-else disagreement scores for that character ran above 4.7 while the other four platforms sat under 2 among themselves. Apple redrew the face in iOS 10 later that year, which is the part worth noticing: the misreading was measurable enough that a vendor changed the artwork. Your iPhone renders a normal grin today because that gap got closed by hand, not by the standard.

The standard guarantees the code point survives the trip. Nothing guarantees the connotation does.

Who decides what gets added

Anyone can propose an emoji. That is not marketing copy — the Unicode Emoji Subcommittee's process takes public submissions from anyone willing to sign the proposal agreement and file a publicly accessible PDF. Submissions run in an annual window; the 2026 one opened on 2 April and closed on 31 July, with decisions going out by 30 November 2026, and the next window opens in spring 2027.

The bar is evidence, not taste. A proposal has to argue expected usage level with actual frequency data — Google Search and Trends, image and video search, Books Ngram — and has to show the glyph is distinguishable at around 18x18 pixels to someone who has never seen it. The standing exclusions kill most ideas outright: logos and brands, specific living or historical people, deities, buildings, UI icons, anything already expressible by combining existing emoji, and anything that opens a series (approve one dog breed and you have signed up for two hundred). Unicode's own summary of the outcome is blunt: a very small percentage advance.

Then it still has to ride a Unicode release, get drawn by every vendor, ship in a font, and arrive in an OS update. From PDF to keyboard is a multi-year path.

FAQ

Why does the same emoji look different on iPhone and Android?

Because the standard encodes the character, not the artwork. Every vendor ships its own emoji font, and design choices drift far enough apart to change how a message reads — the 2016 GroupLens work found platform-pair disagreement scores above 4.7 for a single face. The other half of the answer is age: if the recipient's OS predates the character or sequence, there is no glyph to draw and they get a tofu box or a broken-apart sequence.

Who approves new emoji?

The Unicode Consortium, via the Emoji Subcommittee, which reviews public proposals and forwards a small subset to the Unicode Technical Committee for encoding. You do not need to be a member to submit, but you do need usage evidence, image rights, and a concept that survives the exclusion list.

Is the slightly smiling face actually passive-aggressive?

Not by the standard. U+1F642 was added in Unicode 7.0 in 2014 and its name is exactly "slightly smiling face" — nothing about tone is encoded anywhere. The passive-aggressive reading is a real usage convention, and a generational one: for a lot of people over about 30 it is a plain friendly smile, while a lot of Gen Z readers parse it as a side-eye, so "sure 🙂" reads as anything but. Both readings are correct, which is the problem. In a mixed-age channel, treat it as marked rather than neutral.

The problem Kurita solved is still the problem

The technical fragmentation is genuinely fixed. A code point sent from Tokyo arrives in Toronto as the same code point, and the sequence grammar means new meanings can be assembled instead of endlessly encoded. That is a standards success story, and EmojiSources.txt sitting closed in the UCD is the proof.

What didn't get fixed is the thing Kurita was actually working on: making a picture carry a specific meaning to someone you cannot see. Unicode moved that failure up a layer, from carrier gateways to fonts and generations. It is a rendering and culture problem now, not an encoding one, and no version number is going to close it. Meanwhile, on your side of the wire, the practical takeaway is smaller and more actionable: stop treating an emoji as one character. Segment it, don't slice it.

Cover photo by Tim Witzdam on Pexels.