How New Unicode Symbols Get Approved

It's easy to picture Unicode as an art department that draws new emoji. It isn't. Unicode is closer to a phone book: a registry of numbered addresses, called code points, each permanently tied to one character name. U+1F600 is permanently "grinning face" — that fact never changes.

What does change is the picture. Unicode doesn't draw anything. Apple, Google, Samsung, Microsoft, and every other vendor each design their own artwork for that address, in their own font, in their own style. That's why 😀 looks slightly different on an iPhone than on an Android phone — same code point, same name, two independent drawings of it.

"Unicode symbol" covers two different journeys that share the same finish line. Which lane you're in decides which form you fill out and which committee reads it first.

Both lanes converge at the same place: the same quarterly UTC vote, and the same ISO/IEC 10646 ratification, before either one is published in a Unicode version.

Strip away the two lanes above and every proposal — emoji or not — climbs the same seven rungs. Miss a rung and the climb stops; nothing skips ahead.

No single person or company approves a symbol. Four bodies share the decision, each with a distinct job:

• Unicode Technical Committee (UTC) — the practical decision-maker. Voting membership is made up of organizations (major tech companies among them), and it meets quarterly to move proposals through candidate status to final approval.
• Emoji Subcommittee (ESC) — a working group under the UTC that exists solely to screen emoji proposals against selection factors before they reach the full committee.
• ISO/IEC JTC1/SC2/WG2 — the international standards side. National body delegates (like ANSI for the US) ballot the same additions into ISO/IEC 10646, the parallel standard Unicode is contractually kept in sync with.
• Script & technical experts — for scripts, currency signs, and technical symbols, subject-matter reviewers vet glyph shape and character properties before the UTC votes.

Approval is a vote, not a single gatekeeper's call — which is also why a strong proposal with weak supporting evidence can still stall for a cycle or two.

This is the part most first-time proposers get wrong: rejections are almost never about the artwork. They're about failing one of these factors.

This is the part that matters if you actually want to try. Treat it as a checklist, in order.

1. Confirm which lane you're in. Is this an emoji (a pictograph meant to be drawn by vendors) or a "regular" character, symbol, or script? This decides which form you use and which committee reads it first.
2. For an emoji, use Unicode's official emoji proposal process at unicode.org/emoji/proposals.html. You'll need: a short written rationale, sample images in both black-and-white and full color at multiple sizes, a proposed name and keywords, and — the part people skip — real evidence of demand.
3. For a general character or script, write a full proposal document following the Proposal Summary Form used in Unicode's public document register at unicode.org/L2/. Include the character name, a requested code point range, glyph images at multiple sizes, technical properties (general category, bidirectional class, case mappings, decompositions), and citations of existing published usage. If you also want ISO/IEC fast-track consideration, route a copy through your country's national standards body (e.g. ANSI in the US) alongside the direct UTC submission.
4. Build your evidence file before you write a single sentence of rationale. The strongest proposals cite: published dictionaries or style guides, existing informal encodings people already use as workarounds, frequency or search-trend data, and — where relevant — letters of support from linguistic or cultural organizations.
5. Submit, then expect a wait. Proposals are logged as public documents in the L2 register with their own tracking number. Nothing about this process moves instantly, and a proposal can sit for a full quarter before it's even discussed.
6. Track the quarterly UTC meeting calendar. That's the only point in the cycle where your proposal's status can actually change — there's no other checkpoint to watch.
7. Respond to feedback fast. If the (E)SC comes back asking for a redrawn sample, more evidence, or a narrower scope, a quick turnaround keeps you in the next review cycle instead of slipping a full quarter behind.
8. Know what you're not responsible for. You don't design the final on-screen glyph, you don't need a working font, and there's no submission fee. Unicode ratifies the identity — the code point and the name. The artwork is every vendor's job, done independently, after publication.

Every rung of the Encoding Ladder above is visible in a single live case we track: the UAE Central Bank's new dirham currency symbol, unveiled in March 2025 and submitted for encoding shortly after. As of this writing it's already cleared draft, subcommittee review, and the UTC vote — it was reported approved for encoding in Unicode 18.0 and published in that version's public beta. What it's still waiting on is exactly rungs 6 and 7 above: the final published release (expected September 2026) and then each individual keyboard maker's own decision to actually ship it.

See the full status timeline in our dirham symbol update — it's the clearest real-world proof that "approved" and "on your keyboard" are two separate milestones, not one. For how the same publish-then-wait pattern played out with an entire emoji set, see the Unicode 17.0 emoji rollout.