Why AI pixel art looks bad (and what actually fixes it)

You typed a prompt, got back something that was recognisably your knight or your potion - and it still looked wrong. Not wrong like a bad drawing. Wrong like a photo of pixel art taken through a wet window. If you've felt that without being able to name it, this post gives you the three tells to look for, the one technical reason behind all three, and the honest list of what actually fixes it - including the options that aren't our product.

The three tells

1. Mixels: pixels that don't agree on a size

Pixel artists have a word for the most common giveaway: mixels - mixed-size pixels. In real pixel art, every pixel sits on one grid: a 16x16 sprite has 256 cells and every mark lands exactly in one. AI output routinely has chunky 4-pixel blocks next to fine 1-pixel details, curves that drift half a cell, outlines whose thickness wobbles. Your eye may not name it, but it reads it instantly as "off". Once you see mixels you cannot unsee them - in AI output, in lazy mobile-game asset packs, anywhere.

2. Colour bloat: sixteen colours pretending to be three thousand

Real pixel art works from a small deliberate palette - classically 4 to 32 colours, each chosen to do a job. Diffusion output approximates that look with thousands of slightly-different shades. This is measurable, and you can measure it right here: the two images below are responses to the same prompt - "make me a cobblestone road", both at 16px art scale. Your browser is counting their unique colours as you read this.

That is not a cherry-picked failure - it is what "generate high-resolution, then shrink" necessarily produces. Every scaled edge becomes a gradient of in-between shades. The image on the left has a handful of colours because an artist's process placed each one; the image on the right has thousands because no process ever chose any of them.

3. Mush: edges that anti-alias themselves

Zoom into AI pixel art and the crisp stair-step edges you expect dissolve into soft halos - anti-aliasing the model inherited from photographs and digital paintings. At game scale this reads as blur; against any background it reads as a sticker with a dirty rim. Pixel art's whole visual language is decisiveness - this pixel, this colour, done - and mush is the visible absence of decisions.

One cause, not three

All three tells come from the same place: the model never works in pixels. A diffusion model generates a large soft image - typically 512px or more - in a continuous colour space, and then a downscale-and-quantise step tries to make it retro. Mixels are what grid alignment looks like after averaging. Colour bloat is what a palette looks like after averaging. Mush is what edges look like after averaging. The "pixel art" part was never in the generator; it was a filter applied afterwards, and filters can't add decisions that were never made.

This is also why prompting harder doesn't help. "16-bit style, crisp edges, limited palette" changes what the big soft image depicts - not the fact that it is a big soft image about to be averaged.

What actually fixes it - the honest list

Three real options, in increasing order of automation:

• Clean it up by hand. Pull the output into Aseprite, snap it to a grid, re-quantise to a palette, redraw every edge. This genuinely works - and for one hero asset it can be worth it. For a game's worth of assets you have quietly become the pixel artist you were trying not to need, tracing over AI reference. Budget 20-60 minutes per sprite done properly.
• Hire a pixel artist. Still the gold standard for hero pieces, portraits and key art, and nothing in this post argues otherwise. The honest problem is volume and iteration speed on the long tail - the 40 items, 12 enemy variants and 6 terrain sets a game needs around its hero art.
• Generate under constraints instead of filtering afterwards. This is the approach we build: the AI works like a pixel artist, not an image generator - it places every pixel on the grid, at final resolution, from a fixed palette. There is no downscale, so there is nothing to average: no mixels, no colour bloat, no mush, by construction rather than by cleanup. The same constraint is what makes tilesets genuinely tile and whole projects stay on one style.

If you want to try the constraint-first approach on your own prompt: your first sprite and first paintable tileset are free, in your palette, at the low resolutions this whole argument is about.