alfred-emoji: searching and copying emoji from an Alfred workflow

A keyword search over emoji that ends in a clipboard action

The problem is small but real. Finding one specific emoji in the macOS character viewer takes several clicks and interrupts whatever you were doing. alfred-emoji turns that into a keyword you type into Alfred and a result you act on. The README describes it as an Alfred workflow that makes it easy to search for emoji and copy them to the clipboard. The interaction model is the familiar Alfred one. You type a keyword followed by a query, and Alfred ranks the matches:

emoji [query]

Then the choice of modifier decides what lands on your clipboard, and this is where the workflow earns its keep over a plain emoji picker. Return copies the symbol itself. Option plus return copies the shortcode, the text form such as the ones that begin with a colon. Control plus return copies the Unicode codepoint in the U+ notation. Shift plus return copies the default symbol with no skin tone modifier applied. Command plus return goes one step further and pastes the symbol straight into your frontmost application rather than stopping at the clipboard. Five distinct outputs from one result list is the actual feature. The skin tone modifier, when one is set, changes the default symbol, and the shift action exists to get back to the unmodified version without changing your Alfred setting.

The workflow runs on JXA, which is why macOS is the only target

The README states the dependency plainly: this workflow relies on JXA, JavaScript for Automation, that is built into macOS. That single sentence settles the platform question. JXA lets a JavaScript file drive native macOS applications through AppleScript bridges, which is how the workflow talks to Alfred and to the system character data. Because JXA ships with the operating system, there is no runtime to install and no separate process to supervise, but it also means there is no path to Linux or Windows. The workflow is packaged as an .alfredworkflow file, and the README's loading step opens exactly that file:

npm run load

The package manifest shows what that script expands to:

"load": "npm run build && open alfred-emoji.alfredworkflow",
"clean": "rm -f *.alfredworkflow; rm -rf output/*",
"build": "./build.sh",

So loading the workflow is a build followed by an open, and the build is driven by a shell script at the top of the repository rather than by a JavaScript entry point. The clean script confirms the artifact shape: a single .alfredworkflow file in the repository root, which is what Alfred expects when you double click it or drag it into Alfred's workflow preferences. The workflow directory also holds a webpack configuration and a src directory, so the source is bundled into the workflow file rather than being plain scripts you can read at runtime inside Alfred.

Building from source is how you fix a missing or extra emoji

The README carries an unusually honest warning about the emoji set, and it deserves attention before you install anything. The workflow is built against the latest available macOS within the GitHub continuous integration infrastructure. Two consequences follow from that. Some emoji may be missing until the GitHub infrastructure is updated, and some emoji may be present in the workflow that do not exist on your system if you run an earlier macOS. The fix is stated as well: follow the instructions for generating the workflow on your own system. The build sequence from the README is short:

npm install
npm run build

The manifest notes that Node.js >= 20 is required, so the build is a modern Node toolchain rather than a shell script alone. The generation step is split into two scripts, and the packaging script is separate from the build:

"genpack": "node lib/genpack.js",
"pretest": "npm run genpack",
"test": "node --test",
"lint": "standard | snazzy",

The manifest also lists emojilib, unicode-emoji-json and fontkit as dev dependencies, which tells you where the data and glyph handling come from. emojilib is the keyword library the workflow searches against, and the README links to it separately as the Emoji Keyword Library. unicode-emoji-json supplies the emoji metadata and codepoints, and fontkit is used for glyph rendering information. Building locally on your own Mac is the supported way to align the workflow with the emoji your system actually ships, and it takes two commands.

Skin tone is an Alfred environment variable, not an in-workflow control

Setting the skin tone is the one piece of configuration the workflow exposes, and the mechanism is unusual for an Alfred workflow. You set the `skin_tone` environment variable in Alfred, not inside the workflow. The README lists the accepted values: leaving it unset gives the default symbol, the values 0 through 4 select the individual modifier tones in order, and the value random gives one of the modifiers chosen per copy. Because the setting lives in Alfred's environment configuration, it applies to the workflow's scripts at run time, and it is invisible to anyone looking for a checkbox in the workflow's own settings interface. The workflow compensates with the shift plus return action, which copies the default symbol with no skin tone modifier even while a tone is configured. That pairing is deliberate: it means you can keep a tone as your default and still grab the plain symbol on demand without editing the environment variable. The README does not document how the tone interacts with emoji that have no modifier variants, so expect those to be returned unchanged.

Automatic updates pull from GitHub releases once a day

The workflow updates itself. The README states that it will automatically check for updates at most once per day, and if a new release is found it automatically downloads and installs the latest version of the workflow. All downloads come directly from official GitHub releases, and the download link points at the releases page of this repository. That is a sensible design for a workflow that many people install once and never touch again, and the daily cap limits how often the network is hit. It also introduces a dependency on the release pipeline working. If the tag and the published artifact get out of step, the update path is the same code that ships the workflow, so a broken release propagates to every installation that accepts the update. The README does not describe a way to pin or disable automatic updates, so if you want to control when a new version lands on your machine, you would need to keep the workflow package under your own control and rebuild from source with `npm run build`. For most individual users the default behaviour is convenient. For a machine where software changes need a change record, building from source is the more predictable path.

Where a keyword workflow is the wrong tool

alfred-emoji does one narrow thing well and it is worth being clear about the boundaries. It is macOS only, it requires Alfred, and it requires Node 20 or newer if you want to rebuild it. If you need emoji on Linux or Windows, or if your workflow lives outside Alfred, none of the modifier actions exist. The second limitation is data currency. The README explains that the shipped emoji set reflects the build machine's macOS, so a recent Unicode addition may simply be absent, and on an older macOS the workflow can offer emoji that your own applications cannot render. Regenerating locally fixes both cases, but it means the downloaded workflow and the workflow you built are not the same artifact. The third limitation is search quality, which is inherited from emojilib. The keyword matching is as good as that library's keyword coverage, and the README gives no indication of fuzzy matching, ranking tweaks or a way to extend the keyword set from within the workflow. If you need to search by description, browse by category, or find a specific Unicode codepoint directly rather than by keyword, this is the wrong shape of tool and the macOS character viewer will serve you better.

A JavaScript rewrite of a Ruby workflow, with its own release history

The README credits the original work by Carlos Galdino and explains why this fork exists. His project seems to be unmaintained, with some emoji not copying and some newer ones missing, and it was based on the Ruby language while this one is based on JavaScript. That is a plain statement of a rewrite decision, and the practical reason is the maintenance one: the Ruby original stopped receiving fixes. The rewrite also inherits the ecosystem that comes with Alfred workflows, including the forum post referenced in the README and the separate emoji keyword library it depends on. On licensing, the README links to an MIT License page for this project, and the repository's own license metadata is not populated, so treat the README as the statement of intent rather than a bundled license file you can inspect in the tree. Version 2.4.0 was released on 2026-05-27, following v2.3.1 on 2025-02-14 and v2.3.0 on 2025-02-01, and the last push was on 2026-05-27. The gap between the two February 2025 releases and the May 2026 one shows an irregular cadence, so an install today gives you a workflow whose next update is not on any predictable schedule.

Editorial conclusion

Adopt alfred-emoji if you write frequently in apps on macOS and want keyword search over emoji with clipboard and paste actions, and if the bundled emoji set already matches your system. Do not adopt it if you are on Linux or Windows, or if you need emoji that arrived in a newer macOS release, because the shipped data comes from the build machine and the README explains that mismatch. Before installing, run `npm run build` on your own machine so the emoji set matches your macOS, then set the `skin_tone` environment variable in Alfred to the modifier you want.

Frequently asked questions

Official sources

1. Issues
2. jsumners/alfred-emoji on GitHub
3. README
4. Releases