How to create new emoji: process, standards, and best practices

Overview and getting started

Creating a new emoji starts with understanding that emoji are governed by Unicode, an industry standard maintained collaboratively by technology companies and language experts. To create new emoji, you must contribute a formal proposal that demonstrates need, clarity, and interoperability across platforms. This guide explains how the Unicode Consortium evaluates proposals, the role of vendors like Apple, Google, Microsoft, and Samsung, and how to design emoji that meet technical and editorial requirements.

Unlike quick design experiments, a new emoji can take years to approve and ship, depending on complexity, consensus, and platform release cycles. This evergreen explainer focuses on process, stakeholder expectations, and best practices so your proposal is clear, testable, and ready for implementation.

What are emoji and why standards matter

Emoji are standardized pictographs that enable consistent communication across devices, languages, and platforms. They are not merely decorative images; they are encoded code points with required glyphs, metadata, and semantic expectations defined by Unicode. Standards ensure that a message intended to convey meaning on one device is understood similarly on another, which is why formal submission and review exists.

The Unicode Consortium maintains the Emoji Standard, which references Unicode character encoding while adding emoji-specific guidance on appearance, behavior, and compatibility. Vendors implement these standards in operating systems and apps, which means your proposal must satisfy both editorial clarity and engineering requirements.

Key definitions and terminology

• Unicode code point: A unique number that identifies a character or emoji in computing, written as U+1F300 for example.
• Glyph: The visual representation rendered by an operating system or app for a given code point.
• Emoji variant: A presentation form (text or emoji) selected via Unicode variation selectors, which can change color or monochrome rendering.
• Standardized emoji: An officially encoded code point with approved specification and required glyphs.
• Nonstandard emoji: Symbols created by platforms or apps that are not part of the Unicode Emoji Standard, often incompatible across devices.

When and why to propose new emoji

You should propose new emoji when an important concept, identity, or activity is missing from the standard set and can benefit consistent, interoperable expression. The strongest proposals fill clear gaps, avoid duplication, and demonstrate broad relevance across languages and use cases. Proposals are reviewed for completeness, conflicts, duplication, and implementation feasibility rather than popularity alone.

Consider constraints: some concepts may be better expressed with existing emoji combinations, ZWJ sequences, or stickers and third‑party messaging features. If you proceed, treat the process as a long‑term commitment to maintenance, updates, and alignment with evolving platform designs.

Step-by-step process to create new emoji

Identify the gap and research existing emoji

Before drafting a proposal, map the domain you want to represent and confirm that no existing standard emoji, modifier, or sequence meets the need. Use the Unicode code chart and vendor emoji lists to avoid duplicates and to understand current categorization.

Draft a Unicode proposal (UTS #51)

The official route is to submit a proposal via the Unicode Issue Tracker or through your national body if affiliated with an ISO/IEC member state. A strong proposal includes detailed code point suggestions, context images, sample glyphs, and a rationale that explains uniqueness, frequency of use, and cross‑cultural considerations.

Collaborate with the Emoji Subcommittee and experts

Proposals are reviewed by the Emoji Subcommittee and discussed in meetings where editors evaluate clarity, naming, compatibility, and potential conflicts. Be prepared to iterate on feedback, rename code points, or adjust glyph expectations to align with editorial guidelines.

Address engineering and implementation requirements

Vendors require designs that work at multiple sizes, on light and dark themes, and within existing input UI. Provide scalable vector assets, clear naming, and metadata. Consider accessibility, platform-specific conventions, and how the emoji will behave in text layout and composition.

Align with platform release schedules

Even after Unicode approval, platform vendors ship emoji in operating system updates on their own timelines. A code point approved in one year may appear in major releases months or years later. Track vendor roadmaps and test early builds to understand availability windows.

Proposal contents and editorial standards

A complete proposal contains a title, code point recommendation, glyph sketches, sample images, usage notes, and a clear description of the intended meaning. Editorial standards require gender neutrality where possible, cultural sensitivity, and consistency with existing style patterns such as body parts, objects, and symbols.

Names should be descriptive, stable, and unlikely to change, since they are used in software and documentation. Avoid brand references, trendy phrasing, or culturally narrow jokes that may not translate. Emoji should communicate intuitively across languages while respecting regional diversity.

Technical requirements and compatibility

Unicode defines code points, variation selectors, and default presentation (emoji vs text). Implementations must provide glyphs at multiple sizes, handle bidirectional text, and work with assistive technologies. Test compatibility with major operating systems, browsers, and messaging apps to ensure your new emoji is reliably usable.

If your concept can be expressed today using sequences like ZWJ, consider proposing it as an emoji sequence rather than a single code point. Sequences allow complex ideas without new code points but depend on consistent support across clients.

Tracking progress and common pitfalls

Design and editorial best practices

Focus on clarity at small sizes, cultural neutrality, and legibility across backgrounds. Favor simple shapes over intricate details, and ensure the silhouette remains recognizable when reduced. Provide context of use in sentences and consider how the emoji pairs with existing symbols, skin tone modifiers, and gender options.

Run internal reviews with diverse stakeholders, test in messaging workflows, and document naming conventions early. Because emoji are permanent within the Unicode code space, prioritize names and glyphs that will remain relevant as language and culture evolve.

Platform availability and testing

After Unicode approval, each vendor decides when to implement the emoji in its operating system, keyboard, and messaging apps. Test on current and beta versions of iOS, macOS, Android, ChromeOS, Windows, and major web platforms. Expect differences in color style, size, and placement across keyboards and clients.

Use feature detection in apps when displaying new emoji, and provide nonemoji fallbacks for environments where support is incomplete. Track vendor release notes and platform updates to plan rollouts and user communication.

Maintaining and versioning new emoji

Once published, emoji can receive amendments in future Unicode versions, such as clarifications, additional skin tones, or gender variants. Subscribe to Unicode mailing lists and monitor the Emoji Charts to stay informed about updates, corrections, and errata that affect your emoji.

Plan for versioning in your application: treat new emoji as living standards rather than static assets. Log code points, store glyphs where necessary, and communicate changes to users when cross‑platform rendering differences appear.