Submitting Emoji Character 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. It also describes the process of proposing that existing characters be changed to be emoji.

Submitting a Proposal

To submit a proposal for a new emoji character, prepare a document with the following information, and submit as per How to Submit Proposal Documents.

1. A section that addresses selection factors A through I in Selection Factors, and for each one provides evidence as to what degree each of the proposed characters would satisfy that factor.
   • Some factors may not apply, such as A. Compatibility. If so, explain why.
   • Details under B. Expected usage level must be present, with information as discussed below in Evidence of Frequency.
2. A set of images for the proposed characters. These are to illustrate how each character might be displayed. See below under Images.
3. Suggest where the character should be sorted in Emoji Ordering, namely in which category (such as cat-face) and after which character in that category (such as WEARY CAT FACE).
4. Any other information that would be helpful, such as suggested annotations.

A group of related emoji should be put into a single proposal, especially where the goal is to complete a set (see Completeness).

Some useful examples are the proposals for Dumpling, Food emoji characters, and Female Runner. However, please do not include specific code points (U+XXXXX) for proposed characters or the filled-out Proposal Summary Form. 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.

---

Selection Factors

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.

Factors for Inclusion

1. Compatibility. Are these needed for compatibility with high-use emoji in existing systems, such as Snapchat, Twitter, or QQ?
   • For example, FACE WITH ROLLING EYES.
   • There are many cases where characters are or have been added for compatibility alone, such as SQUARED NEW, or CONSTRUCTION WORKER. In such cases, this is an overriding factor.
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?
      • This is the most important factor for inclusion, after compatibility.
      • There should be high expected usage worldwide, or high expected usage within a particular community of users (such as Indonesians).
   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, card 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.
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 emoji?
   • 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.
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.
   • 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, and (as a candidate) orange; there is no need for finer gradations of color.
5. Frequently requested. Is it often requested of the Unicode Consortium, or of Unicode member companies?
   • For example, HOT DOG or UNICORN.
   • Petitions are only considered as possible indications of potential frequency of usage, among the other selection factors.
   • Citations of petition results should 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.

Factors for Exclusion

6. 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.
7. Open-ended. Is it just one of many, with no special reason to favor it over others of that type?
8. Already Representable. Can the concept be represented by another emoji or sequence?
   • For example, a crying baby can already be represented by CRYING FACE + BABY
   • 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.
9. Logos, brands, UI icons, signage, specific people, 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 . 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 historic or living
   • Deities
10. 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.

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

---

Evidence of Frequency

Different techiques can be used as evidence that the proposed emoji character is likely to be be widely used. The basic goal is to establish the expected frequency of usage compared to a commonly-used emoji of the same type. Thus for a proposed HOT DOG emoji, one can compare against an existing emoji for another food item, HAMBURGER. The relative frequency is the important information.

In the case of emoji proposed on the basis of (A) Compatibility, the relative frequency of usage on the respective platform should be supplied. If hard data cannot be supplied, a estimate with rationale should be provided.

Here are some examples of services you can use. These are not the only methods that can be used as evidence of expected frequency, but proposals should not “cherry-pick”. That is, don't pick only the data that favors the proposed character—present all the available evidence you can find.

Google Trends

• Compare related terms using “Image Search”
• Example: search hot dog vs hamburger, to get two figures (eg, 55 and 66), and divide to get 83%

Instagram

• Compare related items with separate searches for hashtagged items
• Example: perform two searchs for hotdog and then hamburger, to get two figures (eg, 1.3M and 1M), and divide to get 130%

Remember to try related words, both “burger” and “hamburger", for example. It may also be useful to try different languages, such as “paella” vs “hamburguesa”.

---

Images

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 and white images should be in the style used by the Unicode charts. For examples, see Full Emoji Data.

The file names must have the following format: <vendor>_<hex>.png . The <vendor> is a lowercase word consisting of characters in a..z. The <hex> is the lowercase hex value for a proposer-assigned ID in the range e000-efff; when an official code point is assigned, the file name will be updated to use that instead. For images associated with sequences of existing emoji characters, <hex> should use the lowercase value of the code points, separated by _, with all “fe0f” values removed.

	Proposals	Released
<vendor>
Black & White	proposed	n/a
Colored Image	sample, emojipedia, emojixpress, apple, …
<hex>
Hex Code Points	proposer-assigned id (e000, e001, ... efff)	existing

Examples:

proposed_e000.png
sample_e000.png
android_1f004.png
apple_002a_20e3.png
apple_1f915.png

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.

On Bing, choose Type>Clipart

On Google, choose Search Tools>Type>Clipart

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

---

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. To be considered for inclusion in the release of the Unicode Standard for a given year, proposals must be submitted before October 1 of the preceding year. Proposals should be submitted as early as possible in the year, however, to allow time for modifications as described below.
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. Once the proposal is well-formed, and has made a sufficiently strong case for a new emoji character, then it is submitted to the UTC.

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. 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 vendors. However, the cost to such vendors of supporting new emoji characters is also much higher than for most other Unicode characters, especially on devices with limited memory.
   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 would plan to include the proposed emoji character into very widely deployed fonts and input methods (keyboards / palettes / speech).
   3. The committee may balance 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.
3. Those proposals that are accepted as candidates are added to Emoji Candidates, with placeholder code points such as X00002.
4. At the Q4 UTC meeting each year, a decision is made about which of the candidates to accept for encoding in the following year’s Unicode release. Tentative code points are assigned to those accepted. At this meeting the UTC may accept some emoji for encoding, as long as the proposals have been submitted before October 1.

After Acceptance for Encoding

1. The character properties of the characters are specified and appear in the beta property data files for the next release of the Unicode Standard. Implementers have a chance to make sure that those properties are correct, and will not cause problems.
2. 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.
3. The new emoji characters are published in a version of Unicode at the end of June. Once published, they are a permanent part of the standard. Information about them is added to Full Emoji Data.
4. 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
2015 Q4, 2016 Q1	A proposal for 5 emoji characters is submitted to Unicode and referred to the Emoji subcommittee. The proposal goes through three revisions, and is then accepted by the Emoji subcommittee for forwarding to the UTC.
2016 Q2	The UTC considers the proposal, and accepts 3 of the characters as candidates. It asks the Emoji subcommittee to work with the author further on the remaining 2.
2016 Q3	A revised proposal for one of the remaining characters is accepted by the UTC, so it is also now a candidate. The other one is declined. The draft names of the first 3 characters are changed.
2016 Q4	The UTC accepts 3 of the candidates for encoding, assigns tentative code points, and fills out the Proposal Summary Forms. The 4th remains on the candidate list and may be accepted for encoding in a future version of Unicode.
2017 Q1	The draft Unicode Character Properties are completed for the 3 emoji characters, and included in the beta of Unicode v10.0.
2017 Q2	The 3 approved characters appear in Unicode v10.0 at the end of the quarter.
2017 Q2+	Vendors begin to support the 3 new characters.

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

---

Proposing That Existing Characters Become Emoji

The submission process above is for new emoji characters. However, 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.

Proposing to change the emoji properties to include existing characters or sequences as emoji is a much simpler process than submitting a proposal for a new character. The proposal need only provide evidence that an emoji presentation of those characters or sequences would be supported by a reasonably broad set of vendors. The timeline is also shorter. However, proposals for changing emoji properties must be submitted before the Q1 UTC meeting of any year to be candidates for release in that year.

---