[Unicode]  Unicode Emoji Home | Site Map | Search

Submitting Emoji Proposals

Anyone can submit a proposal for an emoji character, but the proposal needs to have all the right information for it to have a chance of being accepted.

This page describes the process of submitting a proposal, including how to submit a proposal, the selection factors that need to be addressed in each proposal, guidelines on presenting evidence of frequency, and the process and timeline for acceptance.

Not all new emoji require new characters. Thus this page also describes the process of proposing that:

Please read this entire page before preparing a proposal. In particular:

Proposals are likely to be declined unless they are complete and adhere to the submission instructions. Other proposals may be returned to the submitter for adjustment based on subcommittee review.

Submitting a Proposal

To submit a proposal for a new emoji, please prepare a document according to the Form for Emoji Proposals. Your document must contain all of the sections shown in the form, and should address, as completely as possible, all of the items specified there.

Each proposal document must follow the Form for Emoji Proposals. When submitting proposals via e-mail, you must include the title in the Subject line.

Once you have completed your document, please follow the directions in How to Submit Proposal Documents to submit it. For timelines, see Process and Timeline.

Form for Emoji Proposals

Title: Proposal for Emoji <name(s)>

The <name(s)> must clearly identify each emoji being proposed, such as Proposal for Emoji: PRAM or Proposal for Emoji: PRAM; STROLLER

Submitter: <name>

The <name(s)> must clearly identify the submitter(s). Use ; between multiple authors.

Date: <date>

When re-submitting revised documents, the document date must still be updated each time.

  1. Identification. Suggested short name and keywords for the emoji, as in the Emoji List.
    1. CLDR short name
    2. CLDR keywords
    3. Proposed emoji names should be general. Adjectives or other narrowing terminology should be avoided except where necessary to distinguish from an existing character. For example, instead of SWAN FACE, the name should be SWAN. Some existing emoji names deviate from this for historical reasons.
  2. Images. One sample color image and one sample black&white image for each proposed emoji must be included in the proposal and in an attached zip file. These are to illustrate how each character might be displayed. The format and license must be as specified in Images.
    1. Zip File
    2. License. The proposer must certify that the images have appropriate licenses for use by the Unicode Consortium, and list the type of license.
    3. Document. The images must be included in the document at the top in two sizes: 18x18 and 72x72 pixels. The 18x18 image is to provide immediate feedback (to you and the committee) as to whether the image is distinctive enough.
  3. Sort location. A proposed sort location for the emoji in Emoji Ordering
    1. Category (such as cat-face)
    2. The emoji in that category that it should come after (such as after 🙀 WEARY CAT FACE).
  4. Reference Emoji. All of the emoji being used for 5.B.1 Frequency. Do not use any emoji except those listed in Reference Emoji.

    The above items must all be at the top of the first page.

  5. Selection factors — Inclusion. A section that addresses all Selection Factors for Inclusion, and for each one provides evidence as to what degree each of the proposed characters would satisfy that factor.
    1. Compatibility
    2. Expected usage level
      1. Frequency (must have separate evidence for each proposed emoji)
      2. Multiple usages
      3. Use in sequences
      4. Breaking new ground
    3. Image distinctiveness
    4. Completeness
    5. Frequently requested
  6. Selection factors — Exclusion. A section that addresses all Selection Factors for Inclusion, and for each one provides evidence as to what degree each of the proposed characters would satisfy that factor.
    1. Overly specific
    2. Open-ended
    3. Already representable
    4. Logos, brands, UI icons, signage, specific people, deities
    5. Transient
    6. Faulty comparison
    7. Exact Images
  7. Other information. Any other information that would be helpful, such as design considerations for images.

Normally, each proposal is for a single emoji. A group of related emoji can be put into a single proposal. However, each of the proposed emoji must have full justification, with all information as if it were a separate proposal. So it is better to have separate proposals for each unless they are extremely closely related.


  • don’t justify the addition of emoji because they further a “cause”, no matter how worthwhile
  • don’t include specific code points (U+XXXXX) for proposed characters
  • don’t include a filled-out Proposal Summary Form.

A proposal may be advanced despite a “cause” argument — if other factors are compelling — but will not be advanced because of it.

The committee will assign code points and fill out the Proposal Summary Form later in the process. The original proposal may then be amended to include those, as was done with the Food emoji characters example below.

The names and images for approved characters may be changed — sometimes substantially — from what is suggested in the proposal. Quite often the name is generalized, for example. A proposal for a brick wall or an iceberg might end up being just for “brick” or “ice” (represented by an ice cube image). The image that a vendor uses typically departs substantially from what is in the proposal, such as to better fit with the “house style” for that vendor.

Example Submissions

Recent successful proposals can be found on Emoji Recently Added. Even more recent (but not yet accepted) proposals can be found on Provisional Candidates and/or Draft Candidates. As you read these, remember the following key facts:

  • New proposals must follow the current Form for Emoji Proposals. This form may have changed since earlier proposals were submitted.
  • A proposal may be accepted for reasons in addition to those stated in the proposal.
  • A proposal may be accepted in spite of material in the text.
    • Proposals sometimes contain material that is irrelevant, or even counterproductive. That material might be ignored by the committee if the proposal is otherwise strong enough.
  • A final name and image accepted on the basis of the proposal might differ from what is proposed.

Sequences & Other Proposals

Not all new emoji require new characters. People can propose that:

The timeline for these proposals is not as long as for new characters, since existing characters can be changed to be emoji or emoji sequences added on a shorter timeline, see Process and Timeline.

You will need to supply color images, but for these proposals you don't need the black and white images.

Making Existing Characters be Emoji

Some characters are already encoded in Unicode; they just aren’t considered emoji (that is, they don’t have emoji properties). These include the chess characters, for example. See Extended_Pictographic for examples of similar characters.

Note that the color images may deviate quite substantially from the Unicode black & white representative images, such as in the Miscellaneous Symbols block. The following table illustrates the how far the emoji image can vary from the black and white, which can be quite minimal and symbolic.

B&W Emoji Code Character Name
🆕 🆕 U+2699 GEAR

However, if the Unicode character is completely symbolic, emojification is not appropriate.

B&W Code Character

If a proposal is accepted for recognizing an existing character as an emoji, the outcome would be a change in the Emoji property value for that character in emoji-data.txt.

New Emoji Sequences

Similarly, new sequences can be proposed for addition. These include:

  • Making a valid sequence be RGI, such as a new ZWJ sequence for dumpster fire represented internally by trash can + ZWJ + fire. Accepting that proposal would result in changes to the data files emoji-sequences.txt or emoji-zwj-sequences.txt.
  • Making an invalid sequence be valid, such as allowing for a skin-tone modifer to apply to a character that it couldn't before. Accepting that proposal would result in a change to the Unicode Emoji specification.

Submission Form Mods

The submission form is almost the same as the Form for Emoji Proposals, but with the following changes.

The <TITLE> is changed to one of

  • Proposal for Changing Characters to Emoji
  • Proposal for New RGI Emoji Sequences
  • Proposal for New Valid Emoji Sequences

The code points of the characters or sequences to be affected must be listed in a new item 1.C Code Points.

Selection factors I, J, and L are not applicable, and should be marked with N/A.


Images must be supplied in a 'flat' zip file (without internal folders).

Images must be in PNG format with dimensions of 72x72 pixels. The image should extend to the sides of the cell (ie, no extra padding). Outside of the main image it should be transparent. Black & white images must be suitable for fonts. Grayscale is not acceptable. Examples:

✅  color ✅  black & white ❌  grayscale

The file names must have the following format:

Non-Unicode members <name>.png
name = the name of the proposal.
Unicode members <vendor>_<hex>.png
vendor = a lowercase word based on a company or product name, such as adobe, android, apple, emojination, emojione, emojipedia, emojixpress, fb, fbm, samsung, twitter, and windows.
<hex> = lowercase hex value(s) of the form [0-9a-f]{4-6}, separated by _, with all “fe0f” values removed.
Provisional candidates Hex values in the range 100000-10fffd
Draft candidates Draft code points as assigned by the UTC
Released characters Assigned code points


New proposal
a195.png name not descriptive
Yawning_face.png uppercase
Advanced to provisional candidate
Advanced to draft candidate
Released, supplied by vendors
1f004.png missing vendor name
emoji_1f004.png bad vendor name
android_1F004.png uppercase
apple_002a20e3.png missing underbar
facebook_2639_fe0f.png fe0f
windows_1f3f3_fe0f_200d_1f308.png fe0f

✅ = Valid, ❌ = Invalid

Duplicate Images

The images supplied for deployed (or in-development) emoji should represent how the system works in practice. For example, if a system uses the same glyph for multiple emoji, then the image should be supplied once for each emoji. This currently occurs on some systems with:

Image Licenses

The images must have appropriate licenses so they can be used on the Unicode site, such as “public domain”, “licensed for non-commercial use”, “free to share and use”, or equivalent (CC: CC0, or BY*). If you have the rights to the image, state that it meets those conditions, otherwise include a link to a page indicating that the license for the image does meet those conditions.

Image Search (or equivalent) can be useful for finding suitable images for proposed characters.

On Bing, choose Type > Clipart & License > Public Domain, such as emu.

On Google, choose Search Tools > Type > Clipart & License > Labeled for noncommercial reuse, such as emu.

You can try filtering for usage rights or license. Sometimes that’s too narrow, and you can find more images with a general search, then clicking through to determine whether the license is suitable.

Selection Factors

There are two kinds of selection factors. Some weigh in favor of encoding the emoji, and some against. These are listed in the sections below.

Selection Factors for Inclusion

Initially, the Unicode emoji characters were selected primarily on the basis of compatibility. The selection factors have been broadened to include other factors; here are the factors that the Emoji subcommittee now considers when assessing possible new emoji. None of these factors alone determine eligibility or priority: all of the factors together are taken into consideration. The most important factors for inclusion are compatibility and expected usage level.

  1. Compatibility. Are these needed for compatibility with high-use emoji in popular existing systems, such as Snapchat, Twitter, or QQ?
    • For example, 🙄 FACE WITH ROLLING EYES.
    • For this to be a positive factor, the proposed emoji must also have evidence of high-frequency use in that existing system.
    • Mark this as n/a unless there are compelling examples.
  2. Expected usage level. (See questions below) Measures that can be presented as evidence include the following:
    1. Frequency. Is there a high expected frequency of use?
      • The evidence of frequency must follow the format of Evidence of Frequency.
      • This is the most important factor for inclusion.
      • There should be high expected usage worldwide, or high expected usage within a very large user community. For example, a community can be geographic, such as users in Latin America or users in Southeast Asia.
    2. Multiple usages. Does the candidate emoji have notable metaphorical references or symbolism?
      • For example, 🐱 SHARK is not necessarily only the animal, but also used for a huckster, in jumping the shark, loan shark, etc. The 🐱 CAT FACE, 🐷 PIG FACE, or 🐰 RABBIT FACE may be used to evoke positive feelings, while 🕷 SPIDER may used to evoke negative feelings.
      • References for use as an archetype, metaphorical use, and symbolism should be supplied.
      • Mark this as n/a unless there are compelling examples.
    3. Use in sequences. Can the candidate be used in sequences?
      • For example, objects associated with professions or activities are of interest for use in sequences: either combined with a person using a ZWJ, or just in linear sequence.
      • Mark this as n/a unless there are compelling examples.
    4. Breaking new ground. Does the character represent something that is new and different?
      • More weight is given to emoji that convey concepts that are not simply variants of concepts conveyed by existing emoji or sequences of existing emoji.
      • For example, it would be better to proposal an emoji for a new kind of animal rather than an emoji for a new breed of dog.
      • Mark this as Yes or No. If yes, explain why.
  3. Image distinctiveness. Is there a clearly recognizable image of a physical object that could serve as a paradigm, one that would be distinct enough from other existing emoji?
    • People should be able to recognize what object an image for the emoji represents, even at small sizes. For example, CASSOULET or STEW probably couldn’t be easily distinguished from 🍲 POT OF FOOD.
    • Simple words (“NEW”) or abstract symbols (“∰”) would not qualify as emoji.
    • Note that objects often may represent activities or modifiers, such as 😢CRYING FACE for crying or 🏃 RUNNER for running.
    • If an existing emoji (or sequence of emoji) is close to the proposed emoji – close enough to be confused at emoji sizes (such as 18x18 pixels) – that is a strong negative factor.
    • Mark this as Yes or No. If yes, explain why.
  4. Completeness. Does the proposed pictograph fill a gap in existing types of emoji?
    • In Unicode 8.0, for example, five emoji were added to complete the zodiac, including 🦂 SCORPION.
    • This factor has a small weight, compared to other countervailing factors, especially low expected frequency. Mark this as n/a unless there are compelling examples.
    • The goal is iconic representation of large categories, not completeness in the sense of filling out the categories of a scientific or taxonomic classification system.
      • Proposals should not attempt to make distinctions that are too narrow. For example, there are emoji for hearts typically drawn as purple, blue, green, yellow, red, …; there is no need for finer gradations of color, like sienna.
  5. Frequently requested. Is it often requested of the Unicode Consortium, or of Unicode member companies?
    • For example, 🌭 HOT DOG or 🦄 UNICORN.
    • Mark this as n/a unless there are compelling examples. Do not simply include listings of examples from social media of people calling for the emoji. That is not reliable enough data to be useful, and just detracts from the strength of your proposal.
    • Petitions are not normally considered as evidence, since they are too easily skewed:
      • Citations of petition results must provide evidence as to how reliable the petition mechanism is (in terms of preventing duplicates or robovotes) and account to what extent the results could be skewed by commercial promotion of the petition.
      • There is a misperception that such petitions play a large role in selecting emoji. For example, the commercial petitions for 🌮 TACO played no part in its selection, because there was no evidence of reliability.

Selection Factors for Exclusion

  1. Overly specific. Is the proposed character overly specific?
    • For example, 🍣 SUSHI represents sushi in general, although images frequently show a specific type, such as Maguro. Adding SABA, HAMACHI, SAKE, AMAEBI and others would be overly specific.
    • A limited number of emoji can be added each year. Thus emoji that “break new ground” are strongly favored over emoji that are variants of others. Thus a proposal for additional species of owl would be viewed negatively.
  2. Open-ended. Is it just one of many, with no special reason to favor it over others of that type?
  3. Already representable. Can the concept be represented by another emoji or sequence, even if the image is not exactly the same?
    • For example, a crying baby can already be represented by 😢👶 CRYING FACE + BABY; a squirrel is already often represented by the chipmunk emoji.
    • A building associated with a particular religion might be represented by a 🛐 PLACE OF WORSHIP emoji followed by a one of the many religious symbols in Unicode.
    • Halloween could be represented by either just 🎃 JACK-O-LANTERN, or a sequence of 🎃👻 JACK-O-LANTERN + GHOST.
    • Note: An image combining two or more other emoji can be represented by an emoji zwj sequence. See examples. Such images are already representable, and do not have to be approved by the Unicode Consortium. They can be requested of vendors.
  4. Logos, brands, UI icons, signage, specific people, specific buildings, deities. Are the images unsuitable for encoding as characters?
    • Images such as company logos, or those showing company brands as part or all of the image, or images of products strongly associated with a particular brand.
    • UI icons such as Material Design Icons, Winjs Icons, or Font Awesome Icons, which are often discarded or modified to meet evolving UI needs
    • Signage such as exit-sign. See also Slate’s The Big Red Word vs. the Little Green Man
      • Note that symbols used in signage or user interfaces may be encoded in Unicode for reasons unconnected with their use as emoji.
    • Specific people, whether fictional, historic, or living
    • Specific buildings or other locations, whether fictional, historic, or modern
    • Deities
  5. Transient. Is the expected level of usage likely to continue into the future, or would it just be a fad?
    • Transient or faddish symbols are poor candidates for encoding.
  6. Faulty comparison. Are proposals being justified primarily by being similar to (or more important than) existing compatibility emoji?
    • Many emoji were added only for compatibility, and would not have been added otherwise. Their existence does not justify proposals for emoji like them. For example:
    • The emoji 🆕 does not justify adding an emoji for ‘OLD’, or an emoji for ‘NEU’ (German). The same is true of the ideographic characters, such as 🈯.
    • The emoji {🐶 🐕} do not justify additional front vs full-body views of the same animal
    • The emoji {🐕 🐩} or {🐪 🐫} do not justify adding different varieties of the same kind of animal
    • Four different mailboxes {📫 📪 📬 📭} do not justify adding your favorite “more important than a mailbox” emoji.
    • The Tokyo Tower🗼 (a specific building) does not justify adding the Eiffel Tower.
  7. Exact Images. Does the proposal request an exact image?
    • Emoji are by their nature subject to variation in order to have consistent graphic designs for a full set. Precise images (such as from a specific visual meme) are not appropriate as emoji; images such as GIFs or PNGs should be used in such cases, instead of emoji characters.
    • Once an emoji is released, it is typically used for a wide variety of items that have similar visual appearance.
  8. Region Flags Without Code. Flags intended to represent specific countries or regions of the world must have a valid Unicode region code (based on ISO/BCP47) or Unicode subdivision code (based on ISO 3166-2).
    • Flags are subject to special criteria which vary by flag type.

Before approving as candidates or adding to a release of Unicode, other considerations are taken into account. See UTC Consideration.

Evidence of Frequency

The goal of this section of your proposal is to gather information that can be used to assess the expected usage level for the new emoji. There is no perfect way to do this, but you are expected to supply the following data to help the committee assess your proposal.

Please read this section and follow all the instructions; otherwise your proposal will likely be rejected.

  • All data needs to be publicly available and reproducible. Of course, search results may vary over time, so the data you provide will be a snapshot at a particular time. The reproducibility must be quick: it cannot require more than a few minutes to reproduce the data you supply.
  • You need to supply screenshots of each result for each of the methods listed below: Google Search, Bing Search, Youtube Search, Google Trends (Web Search), and Google Trends (Image Search). NGram Viewer and Wikipedia Searchs are optional.
    • You can, in addition, supply data using another process that can be used to help establish expected usage levels. In such cases, please indicate why you think it is a useful metric, and supply data for several reference emoji using your process.
  • Make sure that you supply data both for your proposed emoji plus one or more existing “reference” emoji. Bad comparisons will reflect negatively on your proposal:
    • Please do not supply comparisons to items that don't have existing emoji associated with them.
    • Please do not supply comparisons to low-frequency emoji such as 🈁, 🔡, or 🕦.
  • The relative frequency of usage on the respective platform must be supplied, in the case of emoji proposed on the basis of (A) Compatibility. If hard data cannot be supplied, a estimate with rationale should be provided.

For example, it is a waste of time to supply a list of 1,000 data points gathered on Twitter over a month containing “emu”. First, that is not reproduceable without considerable effort, and second, it is useless without comparable data for an existing emoji like “eagle”.

Reference emoji

The reference emoji in the table below are chosen to be about median popularity among existing emoji, and to be reasonably distinct. As with the rest of this section, this list may be updated over time. All proposals are required to use at least one of the emoji in this table for comparison data.

There may not be a representative emoji of the same “type” as what you are proposing. Just pick the closest one. The type is not as important as the emoji being of median popularity.

Type Representative
face drooling face
hand handshake
body nose
role construction worker
fantasy goblin
activity massage
animal elephant
bird penguin
plant rice
food melon
food hamburger
drink tumbler glass
transport ambulance
sport tennis
clothing necktie
computer laptop computer
office scissors
office notebook
tool wrench
symbol warning

Proposed smiley faces need to be assessed differently, since comparison are quite difficult. Generally the best terms capture the particular emoji or reaction, but proposals must be careful to provide evidence that such emotions or reactions cannot be coveyed by the existing smileys.


Proposals for flags are subject to special criteria.

  • Country flags are only valid for countries with Unicode region codes (based on ISO/BCP47). These are added automatically, and do not require proposals.
  • Country subdivision (states, provinces) flags are valid already for all Unicode subdivision codes (based on ISO 3166-2). Only a handful out of the five thousand or so subdivisions have RGI emoji.
    • Adding further subdivision flags as RGI can appear to play favorites unless similar subdivisions also get flags, which could mean “all other flags of that country” or “all subdivisions of greater or equal population in other countries”
    • The frequency of usage for flags tends to be quite low for all but the most prominent, so the committee is not making recommendations until there are better means of assessing the likely frequency of usage. Proposals to add subdivision flags as RGI are brought to the attention of vendors at quarterly UTC meetings.
  • No mechanism currently exists within the Unicode Standard to support flags for regions of the world which do not have a valid Unicode region code (based on ISO/BCP47) or Unicode subdivision code (based on ISO 3166-2). This includes historical flags (for example: South Vietnam) as well as current flags which do not have a corresponding region code or subdivision code (for example: Assyrian, Australian Aboriginal, Kurdistan, Maori, Torres Strait Islander).
  • Other flags (not representing countries, regions, or geopolitical bodies) may be considered for representation as emoji. These are subject to regular Unicode emoji selection factors, such as expected usage, and so on.

Reducing irrelevant results

Reasonable efforts need to be made to remove irrelevant results.

  • Minimize search personalization. Do all of your searches in an “private” browser window where possible, to help remove the effects of search personalization. Private browser windows are opened with menus like the following, depending on the browser: New Private Window, New Incognito Window, InPrivate Window.
  • Supply a category term also. When you search for “mammoth” alone, for example, you may get many irrelevant results, such as “Mammoth Mountain” (a ski resort) or “Mammoth Motocross” (a sports event), etc. So your searches need to be for [mammoth animal] and [tiger animal]. A term like “fly” can be even worse, because of the use as a verb (see below): [fly insect] can pick up items that are not about “flies” but rather other insects that fly. The category terms for each item don't have to be identical, as long as they provide the appropriate filtering. For an example with "bird" and "animal", see below.
  • Quote multiword terms. For example, when searching for black swan, use ASCII quotes around "black swan" and around any multiword category "animal". Otherwise the search data you supply will likely be rejected (without the quotes there could be a hit on a page with “black” in the first paragraph and “swan” in the last). For example, use:
  • Compare parallel terms. For example: do not compare “cheetah” against “tiger face”, nor “spa” against “sauna emoji”. Those will skew any figures because one has a qualifier and the other doesn’t: the correct comparisons would be either
    • “cheetah” against “tiger”, or
    • “cheetah face” against “tiger face”
    • “spa emoji” vs “massage emoji”, or
    • “spa” vs “massage”
  • Choose your language. If your proposed emoji has high usage in a broad region of the world but relatively low usage in English, please also supply the equivalent searches in the appropriate language(s) of that region. Use languages that have the largest literate populations in that region to allow comparison; and please supply the translations from English.
    • That can also be helpful in avoiding irrelevant results in English (such as for “fly”).

Required Information

Remember, each category must have at least two items: the proposed emoji, and a reference emoji from the above list.

Google Search

Bing Search


Youtube no longer shows counts directly. Use a search of the following form:

https://google.com/search?q=site:youtube.com+"black swan"+"animal"

Google Trends: Web Search

This is optional. It is of limited usage, but can be included.

For this case, the category term is chosen when item is selected: you don’t type in [mammoth animal]; you also give both examples at the same time and take one screenshot. You also don't use ASCII quotes. In your screenshot, include enough of the header to see the category.

For this and other tools that let you set start/end dates, use the closest dates you can to the range <Jan 1, 2000 .. present>.

Google Trends: Image Search

This is optional. It is of limited usage, but can be included.

Do the same as for Google Trends: Web Search, but pick Image Search.

NGram Viewer

This is optional. It is of limited usage, since it doesn’t incorporate (even indirectly) social media, but can be included.

For this and other tools that let you set start/end dates, use the closest dates you can to the range <Jan 1, 2000 .. present>.

Wikipedia Search

This is optional. It is of limited usage, since it doesn’t incorporate (even indirectly) social media, but can be included.

For this and other tools that let you set start/end dates, use the closest dates you can to the range <Jan 1, 2000 .. present>.

Please contact us if you have other suggestions for other ways to get pertinent frequency data about expected emoji usage.

Process and Timeline

The following describes the process and approximate timeline for new emoji characters.

Initial Proposal

  1. Submitter reviews Submitting a Proposal (especially the examples), and writes up a proposal.
    • Proposals for new emoji characters must be submitted before March 31 of each year to be considered for inclusion in the release of the Unicode Standard for the following year.
    • Proposals for emojification and sequences must be submitted before Sept 1 of each year to be considered for inclusion in the release of the Unicode Standard for the following year.
    • Proposals are normally processed in the order in which they arrive. Proposals should be submitted as early as possible, however, to allow time for modifications as described below. Submission by the deadline does not guarantee that a proposal will be considered in time for the following year, if too many proposals are received at once.
  2. The proposal is submitted to the Unicode Consortium and then referred to the Emoji subcommittee, which meets weekly by phone. However, there is typically a very full agenda, and it can take up to 30 days (and sometimes longer) for the initial review of a new proposal.
  3. Not every proposal will be forwarded to the UTC for consideration. Some proposals that clearly do not meet the selection critieria, such as proposals to add emoji characters representing logos, specific persons, or deities, are excluded, and the author is informed that the proposal is declined.
  4. Other proposals typically need improvements and clarifications, so the author is informed of problems and asked to make corrections.
  5. Other proposals may be incorporated into a larger list of related characters (such as Foods, or Sports) that is being developed by the emoji subcommittee. Recommendations for consideration of the top characters on these lists is submitted to the UTC. (This is typically a small percentage of each list.)
  6. Once the proposal is well-formed, and has made a reasonably strong case for a new emoji character, then the emoji subcommittee submits it to the UTC. Not all well-formed proposals are forwarded to the UTC. Submission of a proposal to the UTC does not mean that the proposal has been recommended by the ESC. The submission is simply to notify the UTC of a well-formed proposal. For more information, see the Emoji Submission FAQ.

UTC Consideration

  1. The UTC has a quarterly week-long meeting, typically held in the middle of each quarter. Consideration of proposals to add emoji characters is only a portion of the full UTC agenda for each meeting.
  2. Before each UTC meeting, the ESC produces a list of the recommended proposals.
  3. Proposals are discussed, and may be accepted as candidates, or be declined, or returned for more work. Often it takes more than one UTC meeting to get consensus.
    1. Compared to most other characters in Unicode, there is greater public awareness of new emoji characters, and a high expectation of support for them from major platform vendors (such as Android, iOS, Windows, Twitter, and Facebook). Support from major platform vendors is needed to ensure wide distribution of the proposed emoji. Although there is no specific numerical criterion for new emoji use, the goal is usage on the order of millions of daily active users for each new emoji, rather than merely thousands.
    2. Thus in addition to the selection factors, before approving a new emoji character the Unicode Technical Committee needs to expect wide deployment: that major vendors of emoji would plan to include the proposed character into very widely deployed fonts and input methods (keyboards / palettes / speech). Support for more than about 50–100 new emoji a year is problematic for vendors. The cost and complexity to support new emoji characters is much higher than for most other Unicode characters, especially on devices with limited memory.
    3. The committee balances the choices of emoji in a given set of candidates or release. For example, rather than 15 different breeds of dogs, the committee might choose to have some faces, some clothing, other animals, food items, transport items, and sports.
  4. Those proposals that are provisionally accepted by the UTC as candidates are added as Provisional Candidates, with placeholder code points such as X00002.
  5. At the Q2 UTC meeting each year, a decision is made about which of the candidates to advance to Draft Candidates for encoding in the following year’s Unicode release. The candidate pool includes both the Provisional Candidates and proposals processed by the ESC between the Q2 and Q3 UTC meetings.
  6. At the Q4 UTC meeting the subsequent year, a final determination is made as to the emoji characters that are to be in that year’s release. This list constitutes the Final Candidates for the release.

Processing Final Candidates

  1. Code points are assigned to Final Candidates. The emoji property values of the new characters are determined and added to the beta property data files for the next version of Emoji.
  2. Draft short names, keywords, and sort order are added to the beta of the upcoming version of CLDR.
  3. The Unicode character properties of the characters are specified and appear in the beta property data files for the next release of the Unicode Standard.
  4. Implementers have the opportunity to make sure that those properties are correct, and will not cause problems.
  5. After the review of the beta emoji properties is finished, the UTC publishes the final repertoire and emoji property values for that version of Unicode Emoji. This may happen before a version of Unicode is published. Vendors can then start the process of implementation: image design, fonts, keyboards, parsing, segmentation, etc.
  6. After the period for the beta review closes, the UTC determines the final code points and properties, so that the characters are ready for deployment.
  7. The new emoji characters are published in a version of Unicode. Once published, they are a permanent part of the standard. Information about them is added to Full Emoji List.
  8. Unicode member companies may often start preparing fonts, keyboards, and other supporting software for the new emoji characters somewhat before the release, depending on their release schedule.

Sample Timeline

The following is a sample timeline for a typical successful proposal.

Date Description
Y1 Q1 A proposal for 5 emoji characters is submitted to Unicode and referred to the Emoji subcommittee (ESC). The proposal goes through three revisions, and is then accepted by the Emoji subcommittee for forwarding to the UTC.
Y1 Q2 The UTC adds 4 of the characters as Provisional Candidates, declining one of the characters.
Y1 Q3 The UTC reviews the ESC’s overall prioritized list for emoji for the next year, possibly making changes, and makes 3 of these characters be Draft Candidates.
Y1 Q4 CLDR begins translation of the Emoji names and keywords, and determines a sort order.
Y2 Q1 After further review, one of the characters is removed. The rest are advanced to Final Candidate status. The draft Unicode Character Properties are completed for the remaining 2 emoji characters, and included in the beta of Unicode version X. CLDR removes the declined characters, and finalizes the names, keywords, and sort order. Vendors begin design.
Y2 Q2 The 2 approved characters are published in Unicode version X at the end of the quarter, and areincluded in the final data files.
Y2 Q2+ Vendors begin to support the 2 new characters.

Normally proposals need to be submitted to the Emoji subcommittee at least a year before they can appear in a Unicode release.

Process for Proposed Emoji Sequences

The process is simpler for emoji sequences and other proposals that don't require new characters.

  1. If the proposal is not well-formed, the emoji subcommittee responds to the proposer with suggestions for fixing, as is done for new emoji character proposals.
  2. Once a proposal is well-formed, the emoji subcommittee may submit the proposal to the UTC to bring it to the attention of vendors. However, not all well-formed proposals are forwarded to the UTC. For more information, see the Emoji Submission FAQ.
  3. For proposals to make valid sequences be RGI: The emoji subcommittee prepares a summary document for consideration by major vendors.
  4. For proposals to add tag sequences or change emoji properties (such as to make an existing character be emoji): The UTC decides whether or not to change the next version of UTR #51, Unicode Emoji and/or associated emoji data.