# ikatyang/emoji-cheat-sheet: the generated Markdown shortcode reference > A Markdown emoji cheat sheet generated from the GitHub Emoji API and the Unicode Full Emoji List, published as the repository's own README. It is a lookup table, not a library, and the package.json marks the project private. **ikatyang/emoji-cheat-sheet** — A markdown version emoji cheat sheet - Repository: https://github.com/ikatyang/emoji-cheat-sheet - Stars: 13,823 · Forks: 4,600 - Language: TypeScript - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/ikatyang-emoji-cheat-sheet ## The shortcode lookup problem this repository answers Emoji in Markdown are written as shortcodes such as `:grinning:` or `:sweat_smile:`, and the set of shortcodes a platform accepts is not the same as the set of emoji that exist in Unicode. GitHub accepts its own shortcode names, which come from the GitHub Emoji API, and that list drifts as GitHub adds, renames or retires entries. Anyone writing a README, a commit message template or a bot that posts comments ends up grepping for the right name. This repository is the answer to that grep. It is a Markdown file containing a table of emoji, their rendered glyph and their shortcode, grouped into the Unicode categories (Smileys & Emotion, People & Body, Animals & Nature, and so on) with a separate GitHub Custom Emoji section at the end. The audience is narrow and practical: people writing Markdown for GitHub, people maintaining shortcode lists inside another tool, and people who want a plain text file they can search with Ctrl+F instead of a web page with a search box. It is not an emoji rendering library and it does not ship a parser. The repository's own package.json sets `"private": true`, so it is not published as a package you can install and import. What you get is the artifact: the README. ## How the README is generated from two upstream sources The README states that the cheat sheet is automatically generated from the GitHub Emoji API and the Unicode Full Emoji List. That is the whole architecture: two upstream sources, one generator, one Markdown output. The generator lives in the `scripts/` directory. The package.json defines the command that produces the file, and it writes to stdout, redirected into README.md: ```json "generate": "vite-node ./scripts/generate.ts -- run > ./README.md" ``` So the README is not hand-edited. Any manual change to the tables would be overwritten the next time `generate` runs. The category headings and the per-row `[top](#table-of-contents)` links are emitted by the same script, which is why every row carries navigation back to the top of the section and to the table of contents. The generator depends on `jest-playback` as a dev dependency, which records and replays HTTP responses. That detail matters for anyone trying to reproduce the output: the generator is designed to run against recorded fixtures rather than live network calls, so a regeneration does not necessarily reflect what the GitHub Emoji API returns today. The README does not explain the playback setup or how to refresh the recordings, so the mechanism is visible in the dependency list but not documented in prose. The project also has an Up to Date GitHub Actions workflow, whose badge sits at the top of the README. Its purpose, based on the name and the badge link, is to check whether the committed README still matches the upstream sources. The repository does not document what the workflow does when it finds a mismatch. ## Running the generator and grepping the sheet There are no install steps in the README, because the artifact is a Markdown file. You consume it by cloning the repository and reading README.md, or by pointing a tool at the raw file. The repository requires Node.js `>=18` and pins `pnpm@8.6.6` if you want to run the generator yourself. The package.json defines the scripts. `lint` runs `prettier --check .`, `check` runs `tsc --noEmit`, `test` runs `vitest`, and `generate` produces the README: ```json "lint": "prettier --check .", "check": "tsc --noEmit", "test": "vitest", "generate": "vite-node ./scripts/generate.ts -- run > ./README.md" ``` Because `generate` redirects into `./README.md`, running it overwrites the committed file in place. The README does not document a dry-run mode or a way to write the output elsewhere, so if you want to compare before committing, copy README.md first. The dev dependencies you need are listed in package.json: `jest-playback`, `prettier`, `typescript`, `vite`, `vite-node` and `vitest`. Once you have the file, searching it for a shortcode is the first real use. The README gives rows such as `:sweat_smile:` paired with its glyph, and rows with two shortcodes, such as `:laughing:` and `:satisfied:`, appear as two backticked names separated by a `
` in the same cell, which tells you both names render to the same glyph. ## What the generated table cannot tell you The sheet records shortcodes and glyphs. It does not record rendering behaviour, and that gap is where most misuse happens. A shortcode that appears in the table is a shortcode the generator saw in one of its two sources; it is not a promise that every consumer renders it. GitHub's shortcode set, Slack's, and a static site generator's can differ, and the table does not carry a per-platform column. The second limitation is the playback fixtures. Because `jest-playback` is a dev dependency and the generate command runs through it, the committed README reflects whatever responses were recorded, not necessarily the current upstream state. The Up to Date workflow exists to flag that drift, but the README does not state how often it runs, what it compares, or what happens on failure. If you need a shortcode that was added to GitHub recently, the table may not have it yet, and there is no documented freshness guarantee beyond the workflow badge. The third limitation is scope. This is a Markdown table for humans and for grep. It has no API, no exported data structure and no versioned release; the package version is `0.0.0-dev` and the package is private. If you need emoji data at runtime, with Unicode codepoints, categories and skin tone variants in a machine-readable form, you are looking at the wrong artifact. The table gives you a text file, not a dataset. ## Compared with the Unicode Full Emoji List and with gemoji The closest reference is the Unicode Full Emoji List, which is one of this project's own sources. The difference is the axis of lookup. The Unicode chart is organised by codepoint and version, and it answers questions about the standard: when an emoji was added, what its official name is, which codepoints compose a sequence. This cheat sheet is organised by shortcode and answers the GitHub-flavoured question: what do I type between two colons. The other obvious alternative is gemoji, the Ruby gem that ships GitHub's emoji data and is widely used to convert shortcodes to images and back. The difference in approach is packaging. gemoji is a library with a data file you import, so your build step can map `:smile:` to a filename or a unicode character programmatically. This repository is a generated document. If your problem is "I need to convert shortcodes in user input at runtime", a library is the right shape and this is not. If your problem is "I need to look up the shortcode for a face with a thermometer", a table you can search is faster than wiring a dependency into a script. A third comparison is the earlier emoji-cheat-sheet sites, which render a searchable web page. Those give you click-to-copy and visual browsing. This project gives you a file that works in a terminal, in a diff, and offline. That is a real advantage for a certain workflow and a real disadvantage for anyone who wants to browse by picture. ## Maintenance, licence and what a regeneration costs you The repository is not archived, and the last push was on 2026-09-21. The project is a single generated file plus a small script directory, so the maintenance surface is small: the generator, the fixtures, and the workflow. The risk is not code rot but source drift. GitHub can change its emoji API response shape, and Unicode publishes new versions on its own schedule; either event can break or stale the generator, and the fix is in `scripts/generate.ts` plus refreshed recordings. Upgrade cost for a consumer is close to zero in the normal case, because you either clone the file or read it. If you vendor a copy into your own repository, the cost is the diff when you refresh it: the tables are large and Prettier-formatted, so a regeneration can produce a wide diff even when only a handful of shortcodes changed. Pinning a commit hash and refreshing deliberately is cheaper to review than tracking the branch. The licence is MIT, per both the LICENSE file and the `license` field in package.json. MIT is permissive: it allows use, modification and redistribution with the copyright notice and permission notice retained. That is the general shape of the licence, not legal advice, and the emoji data itself comes from GitHub and Unicode, whose own terms are separate from this repository's MIT grant. If you redistribute the generated table commercially, check those upstream terms for the data rather than assuming the MIT licence covers everything in the file. ## Conclusion Adopt it when you need a shortcode lookup you can read, clone or render offline, and when you only need the shortcodes GitHub itself accepts. Do not adopt it as a runtime emoji library, a Unicode width table or a printable poster; the README is a generated table and the package is private. Before relying on it, check the Up to Date workflow status and diff the generated README against the GitHub Emoji API response for the shortcodes you actually use, since the README does not document when the last generation ran. ## FAQ ### Is ikatyang/emoji-cheat-sheet a package I can install from npm? No. The package.json sets "private": true and the version is 0.0.0-dev, so it is not published for installation. You consume it by cloning the repository and reading README.md, or by running the generate script locally. ### Where does the shortcode data in ikatyang/emoji-cheat-sheet come from? The README states that the cheat sheet is automatically generated from the GitHub Emoji API and the Unicode Full Emoji List. The generator is scripts/generate.ts, run through vite-node. ### How do I regenerate the README of ikatyang/emoji-cheat-sheet? Install the dev dependencies and run the generate script, which redirects into README.md and overwrites the committed file in place. The repository pins pnpm@8.6.6 and requires Node.js >=18. ### Does ikatyang/emoji-cheat-sheet work offline? The committed README is a plain Markdown file, so reading and searching it needs no network access. The generator depends on jest-playback as a dev dependency, which suggests it runs against recorded responses rather than live calls, though the README does not document how to refresh those recordings. ## Sources - [ikatyang/emoji-cheat-sheet on GitHub](https://github.com/ikatyang/emoji-cheat-sheet) - [Issues](https://github.com/ikatyang/emoji-cheat-sheet/issues) - [License: MIT](https://github.com/ikatyang/emoji-cheat-sheet/blob/master/LICENSE) - [README](https://github.com/ikatyang/emoji-cheat-sheet/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ikatyang-emoji-cheat-sheet