Ever wondered what happens when you smash š and š„ together? You get a laughing face literally on fire. But here's the thing most people don't realize: Emoji Kitchen isn't doing real-time image processing. There's no AI model stitching stickers together on the fly, no Canvas API blending layers, no clever graphics algorithm running in your browser. The "magic" is actually a massive lookup table and a dead-simple frontend. Let me show you how this thing actually works under the hood.
The Big Surprise: It's Just a Really Big JSON File
When you open an Emoji Kitchen browser like Emoji Monkey, the very first thing it does is fetch a single JSON file ā metadata.json ā weighing in at a few megabytes. That file contains the entire universe of possible combinations. Every single mashup Google has ever drawn is already pre-defined in there.
The frontend doesn't generate anything. It doesn't blend images. It doesn't even know what the final sticker looks like until it loads a PNG from Google's CDN. All it knows is: "If the user picks emoji A and emoji B, the resulting image lives at this specific URL."
This is fundamentally different from how people imagine it works. You might picture some kind of procedural graphics system layering eyes onto faces or swapping colors in real time. Nope. Every single one of those 100,000+ combinations was hand-crafted by Google's design team. The code just looks up which ones exist.
Why Keep It Purely Frontend?
This architecture makes total sense once you think about it:
- Zero server costs: You're not renting GPUs to run diffusion models or paying for image processing. You're serving a static JSON and some JavaScript.
- Instant interaction: No round-trips to a backend mean selecting an emoji updates the UI in milliseconds.
- Privacy by default: Nothing you search or select ever leaves your device. There's no analytics endpoint receiving your emoji preferences.
- Offline-capable: Once that JSON is cached, the whole app works without internet (except for loading the actual PNG images).
- Simple deployment: It's just a static site. Throw it on any CDN and it works globally.
The Data Structure That Powers Everything
The metadata.json deserialized into memory looks like this in TypeScript:
interface EmojiMetadata {
knownSupportedEmoji: Array<string>;
data: {
[emojiCodepoint: string]: EmojiData;
};
}
interface EmojiData {
alt: string;
keywords: Array<string>;
emojiCodepoint: string;
gBoardOrder: number;
combinations: {
[otherEmojiCodepoint: string]: Array<EmojiCombination>
};
}
interface EmojiCombination {
gStaticUrl: string;
alt: string;
leftEmoji: string;
leftEmojiCodepoint: string;
rightEmoji: string;
rightEmojiCodepoint: string;
date: string;
isLatest: boolean;
gBoardOrder: number;
}
This structure is elegant in its simplicity. knownSupportedEmoji is just an array of codepoints like 1f602 (š) and 1f525 (š„). The data map holds every emoji's details, and critically, its combinations field maps other emoji codepoints to an array of EmojiCombination objects.
Why an array for combinations? Because Google sometimes updates a design. The same pair might have an old version and a newer, better-drawn version. The isLatest flag lets the frontend pick the most current one.
Loading the Metadata
On app startup, this single function runs:
let emojiMetadata: EmojiMetadata | null = null;
let loadPromise: Promise<void> | null = null;
const METADATA_URL =
"https://raw.githubusercontent.com/xsalazar/emoji-kitchen-backend/main/app/metadata.json";
export async function loadMetadata(): Promise<void> {
if (emojiMetadata) return;
if (loadPromise) return loadPromise;
loadPromise = fetch(METADATA_URL)
.then((res) => {
if (!res.ok) throw new Error("Failed to load metadata");
return res.json();
})
.then((data) => {
emojiMetadata = data as EmojiMetadata;
});
return loadPromise;
}
Simple memoized fetch. If the metadata is already loaded, return immediately. If a fetch is in flight, wait for it. Otherwise, kick off the request. The app shows a loading spinner until this resolves.
The Lookup Flow: From Click to Sticker
Here's what happens when you actually use the app:
Notice how there's no "generation" step. The browser doesn't create the image ā it just points an <img> tag to a URL Google already prepared.
Rendering the Left and Right Panels
The left panel shows every supported emoji:
export default function LeftEmojiList({
handleLeftEmojiClicked,
leftSearchResults,
selectedLeftEmoji,
}) {
var knownSupportedEmoji = getSupportedEmoji();
if (leftSearchResults.length > 0) {
knownSupportedEmoji = knownSupportedEmoji.filter((emoji) =>
leftSearchResults.includes(emoji)
);
}
return knownSupportedEmoji.map((emojiCodepoint) => {
const data = getEmojiData(emojiCodepoint);
return (
<ImageListItem
onClick={() => handleLeftEmojiClicked(emojiCodepoint)}
>
<img
loading="lazy"
width="32px"
height="32px"
alt={data.alt}
src={getNotoEmojiUrl(emojiCodepoint)}
/>
</ImageListItem>
);
});
}
The right panel is where the "combination logic" lives. When a left emoji is selected, the right panel checks the combinations map to know which emojis are valid partners:
export default function RightEmojiList({
handleRightEmojiClicked,
rightSearchResults,
selectedLeftEmoji,
selectedRightEmoji,
}) {
var knownSupportedEmoji = getSupportedEmoji();
var hasSelectedLeftEmoji = selectedLeftEmoji !== "";
var possibleEmoji: Array<string> = [];
if (hasSelectedLeftEmoji) {
const data = getEmojiData(selectedLeftEmoji);
possibleEmoji = Object.keys(data.combinations);
}
return knownSupportedEmoji.map((emojiCodepoint) => {
var isValidCombo = true;
if (hasSelectedLeftEmoji) {
isValidCombo = possibleEmoji.includes(emojiCodepoint);
}
return (
<ImageListItem
onClick={() =>
hasSelectedLeftEmoji && isValidCombo
? handleRightEmojiClicked(emojiCodepoint)
: null
}
sx={{
opacity: !hasSelectedLeftEmoji ? 0.1 : isValidCombo ? 1 : 0.1,
}}
>
<img
loading="lazy"
width="32px"
height="32px"
alt={data.alt}
src={getNotoEmojiUrl(emojiCodepoint)}
/>
</ImageListItem>
);
});
}
This is the core "algorithm" in the entire app. If hasSelectedLeftEmoji is false, everything is dimmed to 10% opacity because nothing is selectable yet. Once you pick a left emoji, only emojis present in data.combinations become clickable. That's it.
Displaying the Final Mashup
When both emojis are selected, the app resolves the specific combination:
combination = getEmojiData(selectedLeftEmoji)
.combinations[selectedRightEmoji]
.filter((c) => c.isLatest)[0];
// Then renders:
<ImageListItem>
<img alt={combination.alt} src={combination.gStaticUrl} />
</ImageListItem>
The gStaticUrl points to Google's image servers. An example URL looks something like https://www.gstatic.com/android/keyboard/emojikitchen/.../u1f602_u1f525.png. The browser fetches and displays it like any other image.
Search Without a Search Engine
The search feature is entirely client-side too. It debounces input at 300ms and filters against the alt text and keywords array stored in the metadata:
useEffect(() => {
if (debouncedSearchTerm.trim().length >= 3) {
const requestQuery = debouncedSearchTerm.trim().toLowerCase();
const allEmoji = getSupportedEmoji();
const results = allEmoji.filter((codepoint) => {
const data = getEmojiData(codepoint);
return (
data.alt.toLowerCase().includes(requestQuery) ||
data.keywords.some((k) => k.toLowerCase().includes(requestQuery))
);
});
setSearchResults(results);
} else {
setSearchResults([]);
}
}, [debouncedSearchTerm]);
No Algolia, no Elasticsearch, no backend API. Just Array.filter on an in-memory array. It's fast because even with thousands of emojis, modern JavaScript can filter arrays in microseconds.
Randomization: Just Picking from the Lookup Table
The "randomize" buttons aren't generating random combinations algorithmically. They're picking random entries from the existing data:
const handleFullEmojiRandomize = () => {
const knownSupportedEmoji = getSupportedEmoji();
const randomLeftEmoji =
knownSupportedEmoji[
Math.floor(Math.random() * knownSupportedEmoji.length)
];
const data = getEmojiData(randomLeftEmoji);
const possibleRightEmoji = Object.keys(data.combinations);
const randomRightEmoji =
possibleRightEmoji[
Math.floor(Math.random() * possibleRightEmoji.length)
];
setSelectedLeftEmoji(randomLeftEmoji);
setSelectedRightEmoji(randomRightEmoji);
};
Pick a random left emoji, then pick a random key from its combinations object. That's the whole trick. Every "random" mashup is guaranteed to exist because it only picks from entries already in the JSON.
The Emoji Images: Noto Emoji SVGs
For displaying the individual emojis in the left and right lists (not the mashups), the app uses Google's open-source Noto Emoji font. It constructs a raw GitHub URL to fetch the SVG directly:
export function getNotoEmojiUrl(emojiCodepoint: string): string {
return `https://raw.githubusercontent.com/googlefonts/noto-emoji/main/svg/emoji_u${emojiCodepoint
.split("-")
.filter((x) => x !== "fe0f")
.map((x) => x.padStart(4, "0"))
.join("_")}.svg`;
}
This strips out the variation selector (fe0f) and pads codepoints so a9 becomes 00a9 for consistency with Noto's filename convention. The result is a crisp SVG for every emoji in the picker.
What This Architecture Teaches Us
There's a common instinct among developers to reach for complex solutions: machine learning models, serverless functions, image processing pipelines. Emoji Kitchen is a great reminder that sometimes the best engineering is a well-structured lookup table.
Google's designers did the hard work ā drawing 100,000+ unique stickers. The frontend's job is just to navigate that catalog efficiently. By pre-computing every possible output and shipping the index as JSON, you get:
- Sub-millisecond "computation" (it's just a hash lookup)
- Infinite scalability (static files on a CDN)
- Zero maintenance for the combination logic
- Perfect reproducibility (the same inputs always point to the same URL)
Try It Yourself
Browse the full catalog of over 100,000 emoji combinations at Emoji Monkey. Search for your favorites, find the weirdest mashups, and copy them straight to your clipboard ā everything happens right in your browser, no data sent anywhere.

Top comments (0)