Guidelines for Submitting Unicode® Emoji Proposals

This page describes the process and requirements for submitting a proposal for new emoji characters or emoji sequences, including how to submit a proposal, the selection factors that need to be addressed in each proposal, and Guidelines on presenting evidence of frequency.

Emoji submissions are open to the general public, but only a small percentage are accepted for encoding. The Submission needs to be complete and meet the criteria (that is, well-formed) for it to be reviewed. Submissions proposing to emojify existing Unicode characters will not be accepted. If your concept does not require color, consider proposing it as a Unicode character here.

Making a Submission

Please read this entire page and the linked pages before preparing a proposal.

The Consortium licenses its standards openly and freely under various open-source licenses found here and here. Under these licenses, vendors implement encoded emoji into their products to be used all over the world. Therefore, once an emoji is encoded, it can never be removed. For this reason, the Consortium requires a broad perpetual license in any rights you or others may have in your proposed emoji.

So your first step in this process is to read the Emoji Proposal Agreement & License that you will be required to agree to as part of your Submission. This is an important legal agreement in which you (1) warrant that your proposed emoji is available for free and open licensing, and (2) grant to the Consortium broad rights, specifically a non-exclusive irrevocable, perpetual, worldwide, royalty-free license to encode your proposed emoji and to sublicense it under the Consortium’s various open-source licenses.

The Consortium cannot accept any submission that is not accompanied by this warranty and license from you.

Proposals will be rejected unless they are complete and adhere to these Guidelines. Other proposals may be returned to the Submitter for modification based on Emoji Subcommittee review.

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

Once you have exported your proposal as a PDF and prepared the image files, please complete the process by filling out the Unicode Emoji Submission Form with a link to your proposal as a PDF and your images in a ZIP file. Your complete “Submission” will be made up of the completed form, which includes the completed Emoji Proposal Agreement & License (referenced above), your proposal PDF, and your images.

Please keep in mind that many proposals are submitted and we are unable to respond to inquiries regarding the status of your proposal. All submissions will be notified of their status by October.

Format for Emoji Proposals

Title: Proposal for Emoji <name>

The <name> must clearly identify the emoji being proposed, such as Proposal for Emoji: PRAM

Submitter: <name(s)>

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

Date: <date>

When submitting revised proposals, the date must be updated.

Identification. Suggested short name and keywords for the emoji, as in the Emoji List.
1. CLDR short name
2. Other keywords
3. Proposed emoji names should be both general and generic. Adjectives or other narrowing terminology should be avoided except where necessary to distinguish from an existing character. For example, in the case of a proposal for an emoji for “swan,” the name should be swan instead of swan face. Some existing emoji names deviate from this practice for historical reasons.
Images. One sample color image and one sample black&white image for the proposed emoji must be included in the proposal and in a zip file to illustrate how the emoji might be displayed. The format and license must be as specified in the Images section below.
1. ZIP File. Please prepare images in a ZIP file.
2. License. As discussed further in the Images section below, the Submitter must certify that they own all IP Rights in the images, or if not, must identify where the images were obtained and certify that the images are public domain and/or are subject to appropriate open source licenses, thereby making the images suitable for incorporation into the Unicode Standards. Failure to include this information will result in a rejection of the proposal.
3. Document. The images must be included at the top of the document in two sizes: 18×18 and 72×72 pixels. The 18×18 image provides immediate feedback (to you and the Emoji Subcommittee) as to whether the image is distinctive enough at typical emoji sizes.
Category. The proposed category and sort location for the emoji in Emoji Ordering
1. Category (such as food-fruit)
2. The emoji in that category that it should come after (such as after strawberry).
The above items must all be at the top of the first page.
Selection factors — Inclusion. A section that addresses all Selection Factors for Inclusion, and provides evidence for each one as to what degree the proposed emoji would satisfy that factor. For more information, see Selection Factors for Inclusion below.
1. Compatibility
2. Expected usage level
  1. Frequency
  2. Multiple usages
  3. Use in sequences
  4. Breaking new ground
3. Distinctiveness
4. Completeness
Selection factors — Exclusion. A section that addresses all Selection Factors for Exclusion, and provides evidence for each one as to what degree the proposed emoji would satisfy that factor. For more information, see Selection Factors for Exclusion below.
1. Petitions or “frequent requests”
2. Overly specific
3. Open-ended
4. Already representable
5. Logos, brands, other third-party IP rights, UI icons, signage, specific people, specific buildings and landmarks, deities
6. Transient
7. Faulty comparison
8. Exact images
9. Region flags without code
10. Lack of required rights or license for images
11. Variations on direction
12. Includes text
Other information. Any other information that would be helpful, such as design considerations for images.

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, for example). The image that a vendor uses typically departs substantially from what is in the proposal, such as to better fit with the vendor’s “house style.”

Example Submissions

The Emoji Proposals table contains a set of all proposals that have been accepted up to the last release. Proposals that are under consideration can be found on the Beta Candidates page. Proposals that have moved forward (but are not yet Alpha candidates) can be found on the Beta Candidates page. As you read these, remember that new proposals must follow the current Format for Emoji Proposals. This format may have changed substantially since earlier proposals were submitted. The earliest proposals in the Emoji Proposals table date from before the Format for Emoji Proposals was in place.

New Emoji Sequences

Not all new emoji require the addition of a new character. The following can be proposed:

When proposing a new emoji sequence, the proposal title should be changed to one of the following:

The code points of the proposed sequence must be explicitly 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

Images must be in PNG format with dimensions of 18×18 and 72×72 pixels. The image should extend to the sides of the cell (no extra padding). The background of the image should be transparent. Black&white images must be suitable for fonts. Grayscale is not acceptable. Examples:

The file names should reflect the name of the emoji or emoji sequence and the pixel size. For example, the file name “swan-18-bw.png” represents an 18×18 black&white image for a swan.

Image Licenses

The Submitter must warrant that they own all IP Rights (as defined in the Emoji Proposal Agreement & License) in the Proposed Emoji, as Submitter’s own original work and/or by assignment and/or as a work for hire. Or if not, the Submitter must identify where the images were obtained and warrant that the images are public domain and/or are subject to appropriate open source licenses, thereby making the images suitable for incorporation into the Unicode Standards. Specifically, if Submitter does not own all IP Rights in the images, then Submitter must provide a URL to the image on a website where the required license or public domain designation for the image is clearly stated.

When you visit the above URL, the declared license is clearly stated as CC BY 3.0.

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

Failure to include this information will result in rejection of the proposal.

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

Unicode emoji characters were originally encoded on the basis of compatibility. Many emoji seem random or are overly specific to East Asia because the initial set originated from Japan (examples include 🆕 U+1F195 NEW button and 🈯 U+1F22F Japanese “Reserved” button).

Today, there are additional factors that the Emoji Subcommittee considers when assessing proposals. None of these factors alone determine eligibility or priority: all of the factors together are taken into consideration.

Selection Factors for Exclusion

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

Flags

The Emoji Subcommittee and the UTC will no longer accept proposals for flags. Flags for countries with Unicode region codes are automatically added, with no proposals necessary.

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 Emoji Subcommittee assess your proposal.

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

You can additionally, supply data using another process that can be used to help establish expected usage levels. However, you must substantiate why your method is reproducible, and comparable in quality. 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 reproducible without considerable effort, and second, it is useless without comparable data for an existing emoji like “elephant”. Please contact us if you have other suggestions for other ways to get pertinent frequency data about expected emoji usage, before you spend time collecting data.

Proposed smiley faces need to be assessed differently, since comparisons are quite difficult. Generally the best terms capture the particular gesture, expression, or emotion, but proposals must be careful to provide evidence that (a) such emotions or expressions cannot be conveyed by the existing smileys, and that (b) there is a very strong association between the suggested image and the search terms. A good example would be the drooling face emoji, and the search term “drooling.”

Disambiguating Search Results

Reasonable efforts need to be made to remove irrelevant results. In the following, a search phrase (what you would type in the search box) is presented in [square brackets].