How We Built an AI Emoji Generator with Transparent PNG, GIF, and WebP Export

Forgemoji began with a product question: could an emoji combination come from a generated image instead of a fixed lookup table? We wanted the result to leave the browser as a transparent file that people could use in chat. That goal required decisions about model routing, cleanup, resizing, and export. This article follows those decisions.

The product goal

We did not set out to build a general-purpose image model. The workflow has one job: take two emoji concepts, make a new image, remove the background, and return a file that works as a Discord emoji, Telegram sticker, Slack reaction, or social image. The output has to arrive quickly, stay legible at small sizes, and need little cleanup.

A raw model output can look impressive in a gallery and still fail in chat. A muddy background, wrong aspect ratio, or excess detail gets in the way at 32 pixels. We use the generated image as a source asset, then finish it through cleanup, resizing, and format selection.

The generation stack

We keep the layers separate. A model failure should leave export available for a retry. A slow background-removal pass should not hold up the rest of the site. A user who wants a PNG should not wait for an animation step. The separation keeps each failure local.

Why transparent PNG is the default

A transparent PNG is the broadest compatibility format for custom emoji-style assets. Discord accepts it. Slack accepts it. Telegram sticker workflows accept it. Most design tools accept it. In practice, transparency matters more than almost any other export decision because it controls whether the final image blends into the destination UI or looks like a pasted rectangle.

The default export is square, crisp, transparent, and small enough to upload quickly. Animation can then serve users who need it without slowing down the first result. That choice also covers more chat and design workflows.

The background-removal step

Background removal decides whether users can reuse the file or need to repair it by hand. We run a separate pass after generation because model backgrounds vary: they can sit too close to the subject, carry visual noise, or use a solid colour that looks wrong in dark mode.

We generate the image first and remove the background in a separate pass. That gives each stage a clear failure boundary. A strange model result stays visible as a model result; a failed remover can be retried without discarding the generation. The isolated step also lets us change implementations without rewriting the product.

Why we offer GIF and WebP export

Some emoji concepts gain meaning from motion. A bounce, spin, pulse, or soft float can turn a simple image into a useful reaction. The format depends on the destination: GIF offers broad fallback support, while WebP is smaller and often cleaner. We expose both because chat apps and devices handle them differently.

For the animation layer, we render frames and encode them with a dedicated video toolchain rather than asking the browser to do all the work. That gives us predictable output, better compression, and fewer surprises when a user downloads the file on mobile. The resulting image is still easy to share, but it no longer depends on the browser tab staying alive.

The model-routing problem

Model providers go up and down. One day a provider is fast, the next day it is rate-limited, and the next day its latency doubles. The practical solution is boring but effective: keep a routing layer that can fall back to a second or third provider without changing the user-facing experience. Users care that the generator returns something. They do not care which backend produced the answer as long as it is fast and the result is good.

The routing layer also handles provider outages, timeouts, and partial failures. When the primary model is unavailable, the user gets either a usable image or a clear retry path. A blank spinner and a vague error message are not useful fallbacks.

What the browser should and should not do

The browser is excellent at displaying progress, handling input, and rendering the final result. It is less great at doing heavy image-processing work in a way that stays fast on low-end devices. We therefore try to keep the browser role narrow: collect input, show loading state, display result, and let the user export or share. The expensive transformations happen in the pipeline behind it.

This is also why we keep the interface visually clear. When a user clicks Generate, they should understand whether the system is waiting on a model, on background removal, or on export. Ambiguous loading states feel broken even when the backend is working. Clear state labels reduce support requests more than any fancy animation.

What we would do again

• •Keep the core output format boring and universal first, then layer on animation
• •Treat background removal as a separate stage with its own failure handling
• •Use provider routing from day one instead of tying the product to a single model
• •Make the browser responsible for UI, not for the whole image pipeline
• •Prefer platform-specific export settings over one-size-fits-all defaults

Why this matters for the product

Users see the prompt box and Generate button, but the useful work happens after the click. They need a result quickly, few retries, and a file that fits the place where they plan to use it. Those requirements drove the engineering choices in this pipeline.

Forgemoji works because it stays opinionated about the output. The app is not trying to be everything. It is trying to give you a clean, shareable emoji asset with as little friction as possible. That narrowness is what makes the pipeline worth writing about in the first place.

Frequently asked questions

A few practical questions keep coming up whenever people ask how the generator works under the hood. These are the short versions.

Why not just ship MP4 everywhere?

Because MP4 is a video container, not a universal emoji export format. It is great for motion, but many chat apps and sticker workflows want a transparent image file instead. We keep animated export as an option, not the default, because the default should work on the widest number of platforms.

Why not merge generation and background removal into one step?

Separating the steps gives us cleaner error handling and easier debugging. It is much easier to know which stage failed if generation and cleanup are distinct. It also lets us improve one step without reworking the other.

What is the biggest quality bottleneck?

The biggest bottleneck is not the model. It is the final usefulness of the output at small sizes. A result that looks great at 1024px but collapses into noise at 128px is not a good emoji. Small-size legibility is the real quality bar.

How do you decide when an export is good enough?

We judge the output by whether it can be used immediately, without a user needing to open a design tool. If the asset is transparent, readable, and platform-safe, it is good enough. If it needs cleanup, the pipeline has more work to do.

Final note

The simplest way to think about Forgemoji is that it turns a creative idea into a usable file. The model makes the idea visible. The background-removal stage makes it reusable. The export stage makes it portable. Once those three things work together, the product becomes more than a demo. It becomes a tool people can actually trust.

Recommended next reads

• •How We Run AI Emoji Generation at Scale: Routing, Limits, and Failures — explores the systems behind the generator
• •Emoji Accessibility Guide: Making Custom Emoji Readable for Everyone — best practices for inclusive emoji design
• •Generative AI and the Future of Emoji — what comes next after the Unicode model