How to turn an image into pixel art without making it blurry
Shrinking a photo does not make pixel art. What nearest-neighbour scaling, palette reduction and anti-aliasing actually do, and why the export multiple matters more than anything else.
Published
There are two separate disappointments waiting for anyone converting a photo to pixel art. The first is that the result looks like a small blurry photo rather than pixel art. The second is that after fixing that, it still does not look like the pixel art you had in mind.
They have different causes, and only one of them is a settings problem.
The blur has three possible sources
Interpolation during the downscale. When you shrink an image, the software has to decide what colour each new pixel should be. Bilinear and Lanczos resampling average the source pixels that fall into each destination pixel, which is exactly right for photographs and exactly wrong here: averaging across an edge invents a colour that was on neither side of it. Nearest neighbour instead picks one source pixel and copies it, so every output colour is a colour that genuinely existed.
Interpolation during the upscale. This is the one that catches people out, because the file is fine and the display is blurring it. A 64 × 64 PNG shown at 512 px in a browser, a chat app or a store listing gets smoothed on the way up unless something explicitly says not to. Your image is sharp; nobody ever sees it that way.
Anti-aliasing carried over from the source. Text and graphics in the original already have deliberately blended edge pixels. Shrink them and those half-tones survive as isolated muddy pixels that belong to neither shape.
Nearest neighbour, and the half-pixel detail
Nearest-neighbour sampling means: for each destination pixel, work out where its centre lands in the source image, and copy whatever pixel is there.
That word centre is doing real work. It is tempting to sample at each destination pixel’s top-left corner, which is a line of code shorter. The result is an image shifted up and to the left by half a destination pixel — an invisible flaw at photographic sizes, and at 16 × 16 a shift of about 3% of the whole picture, enough to lose a row of an eye or a highlight.
For upscaling, prefer whole-number multiples. At 4× every source pixel becomes a clean 4 × 4 block and the operation is exactly lossless. At 3.7× some source pixels become 4 pixels wide and others 3, so a regular grid acquires an irregular one — the “wobble” that makes an otherwise clean sprite look wrong without it being obvious why.
Palette reduction is where the style comes from
Resolution is only half of it. What makes pixel art read as pixel art is a small, deliberate palette, and it is the part most conversions skip.
Reducing colours means choosing a set and mapping every pixel to its nearest member. Two questions decide the quality:
How is the set chosen? Median cut, introduced by Paul Heckbert in 1982, repeatedly splits the colour space along its widest axis at the median, so each final box holds a similar number of pixels. It is deterministic — the same image always gives the same palette — which matters when you re-run a job expecting your previous result back.
How is “nearest” measured? Straight-line distance in RGB seems obvious and disagrees with the eye, because RGB is not perceptually uniform: a distance of 30 in one region is a barely visible shift and in another an obvious one. Comparing in CIELAB, designed so equal distances look roughly equally different, produces noticeably better matches. This is why two tools with the same palette size can produce visibly different pictures.
A practical range: 8 to 32 colours. Fewer than 8 and photographs turn to mush. More than 32 and you lose the graphic quality that made the reduction worth doing.
Dithering, and when to leave it off
Cut a gradient to 8 colours and you get bands. Dithering trades those bands for texture by spreading each pixel’s rounding error into its neighbours, so a region between two palette colours becomes a fine mixture of both.
- Floyd–Steinberg conserves all the error and keeps the most gradient detail. The best default for photographs.
- Atkinson deliberately discards a quarter of the error, producing crisper, higher-contrast output with blown highlights — the early Macintosh look.
- Bayer (ordered) adds a fixed repeating pattern instead of diffusing, so the texture is a regular crosshatch that reads as unmistakably retro.
Leave dithering off for logos, icons and line art, where flat colour is the point and dithering just adds speckle. Turn it on for photographs, skies and skin.
There is a real trade-off: dithering fights compression. Flat regions compress extremely well in PNG; a dithered region is high-frequency noise, and files can grow several times larger.
Transparency should be all or nothing
Pixel art has no use for partial transparency. A pixel that is 40% opaque is anti-aliasing, which is the thing you are removing. Force alpha to fully on or fully off at a mid-point threshold; otherwise a sprite composited onto a different background shows a halo of half-transparent pixels carrying the old background’s colour.
Why your photo still does not look like pixel art
Now the part that is not a settings problem.
Hand-drawn pixel art is placed. An artist decides each pixel, cleans outlines so they read as continuous lines, exaggerates features that would otherwise disappear, and picks colours that stay distinguishable at a tiny size. Much of the craft is deciding what to leave out.
Conversion cannot do any of that. It faithfully samples what is there, including the detail that no longer fits. A face at 32 × 32 has about a dozen pixels for the eyes, nose and mouth combined — an artist would drop the nose entirely and enlarge the eyes. The algorithm keeps a fair share of all three and you get a smudge.
So use it for what it is good at:
- a base to paint over, which is genuinely how many artists start;
- palette studies, to see how an image survives a given colour set;
- avatars and textures, where suggestion is enough;
- backgrounds and tiles, which tolerate detail loss far better than characters.
And help it along: crop tightly to one subject, raise contrast before converting, and start larger than you think — 64 or 128 — dropping down only once you can see what is being lost.
A workable procedure
- Crop to the subject, hard. Empty background is wasted resolution.
- Raise contrast and saturation a little; palette reduction flattens both.
- Convert at 64 × 64 with nearest neighbour to see what survives.
- Reduce to 16 colours. Try the image’s own palette before a fixed one.
- Add Floyd–Steinberg only if you see banding.
- Drop to 32 × 32 only if the subject still reads.
- Export at 8× or 16× for anywhere you cannot control the display.
What “export at 8×” is really fixing
Almost every “my pixel art is blurry when I post it” problem is this. The file is correct. The platform resizes it with smoothing.
You cannot control the smoothing, so remove the need for it: export at a size
close to how it will be displayed. A 64 × 64 image exported at 8× is a
512 × 512 PNG of hard-edged 8 × 8 blocks, and scaling that by a few percent
does no visible damage. On your own web pages the direct fix is the CSS
image-rendering: pixelated, which tells the browser to use nearest neighbour
when scaling up.
Sources and further reading
- Heckbert, P. “Color Image Quantization for Frame Buffer Display.” SIGGRAPH ’82 — the median cut algorithm
- Floyd, R. W. & Steinberg, L. “An Adaptive Algorithm for Spatial Greyscale.” Proc. SID 17(2), 1976
- Bayer, B. E. “An optimum method for two-level rendition of continuous-tone pictures.” IEEE ICC, 1973
- CIE 15:2018 Colorimetry — the definition of CIELAB
- IEC 61966-2-1 — the sRGB colour space and its transfer function
- MDN —
image-rendering: pixelated
Last reviewed 31 July 2026.