How to make pixel art that looks right

Pick two numbers before you draw anything

Pixel art is defined by scarcity. Not by a retro aesthetic, not by a particular program, and not by visible squares — by the fact that you have very few pixels and very few colours, and every one of them therefore has to carry meaning. Get those two numbers right and mediocre drawing still reads as pixel art. Get them wrong and excellent drawing does not.

The first number is resolution: how many art pixels wide your piece is. Not how large it appears on screen — how many squares actually exist. Classic reference points are useful here. An NES sprite was 8×8 or 16×16. A Game Boy screen was 160×144 in total. Most modern indie sprites live between 16×16 and 64×64, and most beginners start at 200×200 and quietly wonder why their work looks like a small illustration rather than pixel art. It is because at 200×200 there is enough room to draw normally, and drawing normally is exactly what the medium is not.

The second number is palette size. Four to sixteen colours for a single sprite is a sane range; thirty-two is generous. The instinct to add one more shade for a slightly different highlight is the instinct to fight, because every added colour dilutes the ones already there. Hardware palettes enforced this historically — the NES allowed three colours plus transparency per sprite — and the constraint is why that era's art still reads clearly at thumbnail size.

These two numbers interact. A small palette on a large canvas looks flat and empty. A large palette on a small canvas looks noisy, because there is no room for a gradient and the extra colours end up scattered as single-pixel speckle. Keep them proportional: small canvas, small palette.

What to avoid

Google attaches this question to the search twice over, which is a fair reflection of how the craft is learned — mostly by recognising mistakes after making them. These are the ones that show up most.

Mixed resolution is the biggest and the least often noticed. It happens when part of your image is made of 4×4 blocks and another part is made of single pixels — usually because something was scaled, or pasted in from a different-sized source, or drawn at a different zoom level. The result reads as broken rather than stylised, and no amount of detail work fixes it. One art pixel must be the same size everywhere in the piece, without exception.

Automatic anti-aliasing is the second. Software that smooths edges for you inserts semi-transparent in-between pixels along every diagonal, which quietly triples your colour count and softens exactly the hard edges the style depends on. Note that manual anti-aliasing — deliberately placing a mid-tone pixel at a specific corner to smooth a curve — is a legitimate and advanced technique. The problem is never that intermediate pixels exist; it is that the program chose them and you did not.

Jagged lines, or 'jaggies', are the third. A pixel line drawn at an angle is a staircase, and the staircase needs a consistent rhythm: steps of 1-1-1, or 2-2-2, but not 2-1-3-1. Irregular step lengths read as a wobble even to viewers who could not tell you what they are seeing. When a line looks wrong and you cannot say why, count the steps.

Over-dithering is the fourth. Dithering — alternating two colours in a pattern to fake a third — is genuinely useful for large gradients like a sky. On a 32×32 sprite it mostly produces noise that the eye reads as JPEG damage. Use it on big flat areas or not at all, and be willing to switch it off entirely, which is a real option and not an admission of defeat.

Non-integer scaling is the fifth, and it is the one that destroys finished work at the last moment. If a 64-pixel image is exported at 500 pixels wide, that is 7.8125 screen pixels per art pixel — so some art pixels are 8 wide and others are 7, and the whole grid visibly stutters. Always scale by whole numbers: 2×, 4×, 8×. Related: never save pixel art as JPEG. JPEG compression is built to blur hard edges, which is the entire content of your image.

• Mixed resolution — one art pixel must be one size across the whole piece
• Automatic anti-aliasing — manual is a technique, automatic is damage
• Jaggies — keep the staircase rhythm consistent (1-1-1 or 2-2-2, not 2-1-3)
• Over-dithering — fine on a sky, noise on a 32×32 sprite
• Non-integer scaling and JPEG export — both undo the work at the final step

From scratch, or from an image

There are two honest routes in, and they suit different goals. Being clear about which one you are on saves a lot of frustration, because the advice for each is nearly opposite.

Drawing from scratch means opening a small empty canvas and placing pixels one at a time. It is the route if you want game sprites, animation, or a personal style, and it is a genuine skill that takes months rather than afternoons. Start with a 32×32 canvas, a six-colour palette, and a silhouette — the shape has to be readable in solid black before any detail is worth adding. Expect the first twenty attempts to be bad in ways you cannot diagnose yet; that is the normal shape of learning this.

Converting an image means starting from a photograph or an existing drawing and reducing it — fewer pixels, fewer colours. It is the route if you want an avatar, a wallpaper, a cross-stitch or perler bead pattern, or a reference to trace over. It takes seconds rather than months, and it is not cheating: reducing a photo to 48×48 with a sixteen-colour palette forces exactly the same decisions about resolution and palette described above, it just makes them with sliders instead of a stylus.

The conversion route is also the fastest way to develop an eye for the first section of this article. Load a photo into the pixel art converter, then drag the pixel size slider from 2 up to 24 and watch the point where the image stops being a small photograph and starts being pixel art. Then cut the palette to four colours and watch what survives. Ten minutes of that teaches the resolution-and-palette relationship more concretely than reading about it, and nothing is uploaded anywhere while you experiment.

Many people end up using both: convert a reference photo to establish the palette and proportions, then redraw over it by hand. That is a long-standing workflow, not a shortcut.

Making pixel art on a phone

The desktop editors that professionals recommend — Aseprite, Pixelorama, GraphicsGale — do not run on a phone, which is why this question comes up so often and gets answered so poorly.

For drawing by hand on mobile, dedicated apps exist on both app stores, and the honest caveat is that a fingertip is roughly forty screen pixels wide while an art pixel at a comfortable zoom is about ten. Precise single-pixel placement on a touchscreen is genuinely awkward. A stylus helps enormously; without one, expect to zoom in much further than you would on a desktop and to use undo constantly.

For converting an image on mobile, the situation is much better, because the work is done by sliders rather than by precise taps. A browser-based converter runs on a phone with no install and no account — the pixel art converter and the photo converter on the home page both work from a mobile browser, processing the image on the device itself rather than uploading it. If your source photo is already on your phone, that removes the transfer step entirely.

What programs people actually use

For drawing sprites by hand, Aseprite is the near-universal answer among people who do this professionally. It is paid and inexpensive, it understands art pixels rather than file pixels, it enforces a palette, and it has proper frame-by-frame animation. Pixelorama is the free open-source alternative and is genuinely capable — if budget is the constraint, it is not a compromise you need to apologise for. LibreSprite is a free fork of an older Aseprite release and also works.

Photoshop can be configured for pixel art, and plenty of people use it because they already have it, though it takes several setting changes before it stops blurring everything — see our Photoshop setup guide for the specific ones. Procreate on iPad is in a similar position: capable once configured, not built for this.

For converting rather than drawing, a browser converter is faster than any of the above, because the job is three decisions and none of them need a canvas. That is the split worth remembering when choosing: dedicated editors are for making pixels; converters are for making pixel art out of something that already exists.