What models return is a picture of pixel art, not pixel art. A sprite generated for this article asked for twelve colours and came back with 44,725, on a grid whose "pixels" varied between 26 and 32 pixels wide. Two steps fix it: downsample with nearest-neighbour, then quantise the palette.
Ask any current image model for a 32×32 sprite and it will hand you something that looks convincingly retro at a glance. Open it in a sprite editor and the illusion collapses, because the file is a high-resolution painting of blocks rather than a grid of them.
That distinction sounds pedantic until you try to use the result. This article measures exactly how far off a generated sprite is, then fixes one and measures again.
Want to try it? Rangy runs the models on your own API key at about five cents a generation, so iterating on a sprite is cheap.
Try it freeIs AI pixel art actually pixel art?
No, and the gap is larger than it looks. The sprite above was requested at 32×32 with about twelve colours. The returned file measured 44,725 unique colours, and only 2% of its colour changes landed where a true 32×32 grid would put them.
The three properties that define pixel art are all missing:
- One uniform grid. Measured across the sprite, the width of a single apparent "pixel" varied between 26 and 32 image pixels. Real pixel art has exactly one block size, everywhere.
- A limited palette. Forty-four thousand colours is a photograph's worth of tonal range, applied to something meant to have twelve.
- Hard edges. About 4.5% of the image is transitional pixels blending one block into the next. In a real sprite scaled up, those boundaries are infinitely sharp.
The requested resolution is not honoured either. Working back from the measured block width, the model drew at roughly seventy units across rather than the thirty-two it was asked for.
Why can't models just make it properly?
Because pixel art is a constraint, not a style, and models are trained to produce a look rather than obey a rule. Everything about how they generate — continuous colour space, smooth transitions, resolution decided by the sampler — works against a strict grid and a fixed palette.
It is worth understanding this because it predicts what will and will not improve. A model can learn the aesthetic of pixel art from millions of examples: chunky forms, limited-looking colour, readable silhouettes. It cannot learn to snap output to a lattice it has no concept of.
Which is also why prompt engineering does not rescue it. "Exactly 32 by 32", "no anti-aliasing", "strict twelve-colour palette" were all in the prompt that produced the sprite above. The model complied stylistically and ignored every requirement literally.
How do you turn it into real pixel art?
Two operations, both lossless in intent. Downsample to your target sprite size using nearest-neighbour so no new colours are invented, then quantise the palette to a fixed number of colours. Applied here, that produced exactly 16 colours with 100% of colour changes on an exact grid.
The order and the settings both matter more than they look:
- Nearest-neighbour, never bilinear or Lanczos. Smooth resampling averages neighbouring pixels and creates the exact soft edges you are trying to remove. Every editor calls this something different — "nearest neighbour", "hard edges", "no interpolation".
- Downsample first, quantise second. Reducing colours on the full-size image then shrinking re-introduces blends.
- Turn dithering off. Quantisers default to dithering, which scatters pixels to fake intermediate tones. That is the opposite of a flat palette.
- Then clean up by hand. The conversion gets you a correct file; it does not get you good pixel art. Stray single pixels and broken outlines still need fixing.
What the numbers actually became. The same sprite at 64×64 with a 16-colour palette measured exactly 16 colours, with every colour change falling on a true block boundary. At 32×32 with 12 colours it measured exactly 12. The file becomes real pixel art at that point — the question is whether the artwork survives, which is the next section.
What sprite size should you target?
64×64 is the sweet spot for a generated character. It keeps the face, the shield detail and the belt readable. At 32×32 you keep the silhouette and lose the face; at 16×16 the result needs redrawing by hand rather than converting.
This is the practical reason generated sprites suit some projects and not others. If your game's art direction is 32×32 or smaller — which covers most authentic retro styles — conversion will not carry a generated character's detail, and you are better off using the output as a reference to draw from.
If you are working at 64×64 or above, which covers a lot of modern indie work, the conversion is genuinely usable.
How many colours should you use?
Roughly one colour per four pixels of sprite width, as a starting heuristic. A 64×64 sprite works at about 16 colours, 32×32 at about 12, and 16×16 at 8. Fewer colours than that reads as deliberate style; more starts to look like a downscaled photograph.
The count matters more than the specific hues because it controls whether the result reads as pixel art at all. Thirty-two colours on a small sprite produces subtle gradients across a few blocks, which is precisely the thing that makes generated output look wrong.
If you are matching an existing project, quantise to that project's actual palette rather than to a number. Most editors accept a palette file, which forces every pixel to a colour your other art already uses — the only way a converted sprite will sit next to hand-drawn ones without looking imported.
What survives the conversion and what does not?
Silhouette, pose and colour identity survive well. Fine internal detail, small text, thin lines and anything below a couple of blocks wide do not. The conversion is a resolution cut, so anything that needed the extra resolution is simply gone.
- Survives: overall shape, readable pose, the character's colour scheme, large shapes like a shield or a cloak.
- Degrades: facial features, hands, weapon detail, anything patterned.
- Disappears: lettering, thin outlines, single-pixel highlights, texture.
The practical consequence is to prompt for simplicity in the first place. A generated sprite with a bold silhouette and few internal elements converts far better than a detailed one, because you are going to throw most of the detail away regardless.
Can you generate animation frames?
Not reliably. A walk cycle needs the same character in the same palette with only the intended limb positions changing, and frame-to-frame consistency is the weakest area of current image models. You will get a set of similar-looking poses rather than an animation.
This compounds badly with the conversion step, because each frame quantises to a slightly different palette unless you force a shared one. Even small differences read as flickering when the frames play at speed.
If you do try it, generate every frame in one image as a sheet rather than separately — the same batching logic as in the game assets guide — and quantise the whole sheet at once so all frames share a palette. It still will not be a clean cycle, but it will at least be consistent in colour.
When should you just draw it yourself?
When the target is 32×32 or smaller, when you need animation, when the sprite has to match existing hand-drawn art, or when the game's identity is its art. Pixel art at small sizes is a craft of individual decisions, and there are not many pixels to hide a wrong one behind.
Stated plainly, because this guide is published by a company that sells image generation:
- Small sprites are faster to draw than to fix. A 32×32 character is about a thousand pixels. An experienced artist places them quicker than you will clean up a conversion.
- Consistency across a set is where hand work wins outright, because a person holds the palette and the style in their head.
- Animation is not a generation problem. It is a timing and weight problem.
- Where generation genuinely helps is exploration: twenty character concepts for a dollar, then draw the one you liked.
That last point is the honest use case. Treat the output as concept art that happens to look chunky, not as an asset.
Frequently asked questions
Can AI generate real pixel art?
Not directly. A sprite generated for this article requested twelve colours and returned 44,725, with apparent pixel blocks varying between 26 and 32 image pixels wide instead of one uniform size. It looks like pixel art and is not structured like it. Converting afterwards with nearest-neighbour downsampling and palette quantisation produces a genuine sprite.
How do I convert an AI image to pixel art?
Downsample to your target sprite size using nearest-neighbour interpolation so no new colours are invented, then quantise the palette to a fixed number of colours with dithering turned off. Do it in that order — quantising before downsampling reintroduces blended edges. Expect to clean up stray pixels and broken outlines by hand afterwards.
What sprite size works best for converted AI art?
64 by 64 pixels. At that size the face, equipment detail and colour identity all survive the conversion. At 32 by 32 you retain the silhouette but lose facial features, and at 16 by 16 the result needs redrawing rather than converting. If your project's art direction is smaller than 64, use generated output as reference instead.
Why does my AI pixel art look blurry when I zoom in?
Because the edges are anti-aliased. Around 4.5% of the generated file measured here consists of transitional pixels blending one block into the next, which is invisible at normal size and obvious when magnified. Real pixel art has no transitional pixels at all. Nearest-neighbour downsampling removes them.
How many colours should a pixel art sprite have?
Roughly one colour for every four pixels of sprite width as a starting point: about 16 for a 64 by 64 sprite, 12 for 32 by 32, 8 for 16 by 16. If you are matching existing artwork, quantise to that project's actual palette file instead of to a number, which is the only way a converted sprite sits next to hand-drawn work convincingly.
Can I generate a pixel art walk cycle?
Not reliably. Frame-to-frame consistency is the weakest area of current image models, so you get similar-looking poses rather than an animation, and each frame quantises to a slightly different palette unless you force a shared one. Generating all frames as one sheet and quantising the sheet together at least keeps the colours stable.
Does prompting for "no anti-aliasing" help?
Not measurably. The prompt behind the sprite in this article specified 32 by 32, about twelve flat colours, hard aliased edges, no gradients and a uniform grid. The model matched the style and honoured none of the constraints literally. Prompt wording changes the look; it does not change how the image is generated.
The bottom line
Generate for the look, convert for the format, and draw by hand for anything small or animated. Nearest-neighbour to your target size, quantise to a fixed palette, dithering off — two operations that turn a picture of pixel art into an actual sprite.
The interesting part of measuring this was how convincing the unconverted file is. It reads as pixel art in a blog post, in a thumbnail, and in a pitch deck. It stops reading as pixel art in the one place that matters, which is a sprite editor next to real assets.
So the honest framing is not that models are bad at pixel art. It is that they are producing a different artefact than the one being asked for, and the conversion is your job.
"This software has increased my workflow speed tenfold, and the output quality it has delivered in my work has been exceptional."
Generate twenty concepts for a dollar
Rangy runs GPT Image 2, Seedream and the rest on your own API key from about two cents an image, several at a time — useful when the plan is to explore characters cheaply and draw the one that works.
Download Rangy Free Or read the game assets guide →Mac & Windows · Free plan, no credit card · 5 generations a day
One sprite was generated with GPT Image 2 at 2K for $0.05, requesting 32×32, about twelve flat colours, hard aliased edges, no gradients and a uniform grid. Every figure quoted is measured from that file rather than estimated: unique colours counted directly; transitional pixels counted as those adjacent to a colour change; apparent block width derived from the spacing between colour changes along a scan of the sprite; grid conformance measured as the share of colour changes falling on a true 32×32 lattice. The conversion used nearest-neighbour downsampling followed by median-cut quantisation with dithering disabled, and the resulting files were re-measured the same way — 16 colours at 64×64 and 12 at 32×32, with every colour change on an exact block boundary in both. The size ladder shows that same source sprite converted at four targets. All images are shown unretouched.
This guide is published by Rangy, which makes an image generation tool, so it is not a neutral source. It also concludes that small sprites and animation are faster to draw by hand, which is in when to draw it yourself.