How to make pixel art for a 2D game, from blank canvas to export

Pixel art looks simple from across the room and gets surprisingly fussy up close. Every square is a decision, and on a 16 by 16 sprite you only have 256 of them. That is the good news, too: the canvas is small enough that you can finish something in an evening, see what went wrong, and do it again the next night. This is the order I work in when I start pixel art for a game, from picking a canvas size to exporting files a game can draw without blurring them.

I will assume you have a pixel editor. Aseprite is the one most people I know use, and free editors such as LibreSprite or Pixelorama do the same basic jobs. Any editor works as long as it has a pencil with no smoothing, a grid, and a palette panel. If you are still putting your setup together, the toolbox page has a broader list of tools for small game projects.

Step 1: decide the canvas size before anything else

The most common beginner mistake is drawing at whatever size the editor opens with, then discovering the sprite does not fit the game. Pick the size from the game, not from the art.

Start with the screen. A lot of pixel games render to a small internal resolution and scale it up by a whole number. Then ask how many tiles or characters you want to see across that screen. A small worked example:

All four rows scale to 1080p by an integer, which is the property you want. The choice between them is about how much of the world the player sees and how much detail each object gets. A 16 pixel character on a 320 by 180 screen feels close and chunky. The same character on 480 by 270 feels like a small figure in a big place.

For a first project I suggest 16 by 16 tiles and a character between 16 and 24 pixels tall. That is small enough to be quick and large enough to show a face. Write the numbers down somewhere. You will want them again when you set up the camera and the tile map.

Step 2: choose a small palette and stick to it

A palette is a limit, and limits are what make pixel art look like pixel art. With unlimited colours you end up with dozens of nearly identical shades that do nothing except make the image muddy.

For a first sprite, take 8 to 16 colours. You can borrow an existing palette (many editors ship with a few, and palette collections are easy to find) or build your own. If you build one, think in ramps rather than single colours. A ramp is a short run of colours from dark to light that you use to shade one material.

A useful habit when building a ramp: shift the hue as you go, not only the brightness. Shadows lean slightly towards blue or purple, highlights lean slightly towards yellow. A green ramp for grass might run from a dark blue green, through a mid green, to a light yellow green. Ramps built only by darkening the same hue tend to look grey and flat in the shadows.

Here is the kind of starter palette I sketch before a jam, written as hex values in a plain text file:

outline     #1a1423
skin dark   #8f4f45
skin mid    #d98a6c
skin light  #f2c6a0
cloth dark  #2b3a67
cloth mid   #3f6db3
cloth light #7fb2e5
grass dark  #23432f
grass mid   #4f8a3c
grass light #a4c95b
accent      #e8c547

Eleven colours, three ramps, one dark outline and one accent. That is plenty for a character and a patch of ground. Load it into your editor and lock it so you cannot accidentally pick a stray colour from the colour wheel.

Step 3: block in the silhouette

Now draw. Use a single mid tone and fill the shape of the thing, with no outline and no shading. Stay zoomed out enough that you can see the sprite at the size the player will see it. Most editors let you open a second preview window at 100 or 200 percent, and that preview matters more than the zoomed in canvas.

Ask one question: can you tell what it is from the solid shape alone? A mushroom should read as a mushroom as a flat blob. A character should show where the head is and which way they face. If the silhouette is unclear, no amount of shading will save it, so fix it now while it costs nothing.

At 16 pixels, proportions get exaggerated. Heads are large, often a third to a half of the total height, because the face needs room. Hands and feet are a single pixel or two. Do not fight this. Small sprites are closer to icons than to drawings.

Step 4: outlines, and when to drop them

Once the silhouette works, add an outline. A dark outline separates the sprite from any background, which is why so many games use one. The trick is to keep it one pixel wide and to avoid what pixel artists call doubles: places where the line steps sideways and two pixels end up touching along an edge, making the line look thick and lumpy.

Lines in pixel art read best when their steps follow a steady rhythm. A diagonal of one pixel across, one down is clean. Two across, one down is clean. A run like two, one, three, one looks wobbly, because the eye sees the irregular steps.

You do not always need a black outline. Two common variations:

• Coloured outlines, where the outline uses the darkest shade of each area's ramp instead of one universal dark. The sprite looks softer and more painted.
• Selective outlines, where the outline is dark on the shadow side and lighter, or missing, on the lit side. This suggests a light source with almost no extra effort.

Try the plain dark version first. It is the easiest to read, and you can soften it later.

Step 5: shading with clusters

Shading in pixel art is less about smooth gradients and more about clusters: groups of the same colour that sit together and form a clear shape. A good cluster has a definite outline of its own. A bad one is a speckle of single pixels scattered across the surface, which reads as noise at game size.

Pick a light direction and keep it. Top left is traditional and works fine. Then for each area:

1. Leave the mid tone as the base.
2. Paint a cluster of the dark shade on the side away from the light.
3. Paint a smaller cluster of the light shade on the side facing it.
4. Look at the preview, not the canvas.

Avoid pillow shading, which is shading every shape from the outline inwards as if it were a cushion lit from the front. It is the first thing everyone does, and it flattens volume instead of creating it. The light should come from one side and the shadow should sit on the other.

Step 6: anti-aliasing by hand

Anti-aliasing in pixel art means placing intermediate colours by hand where a line or edge would otherwise look jagged. An editor's automatic smoothing produces dozens of blended colours you did not choose. Doing it yourself keeps you inside the palette and keeps the image crisp.

The method is small. Where a curved line steps from one row to the next, put a pixel of a middle colour in the inside corner of the step. That pixel is darker than the background and lighter than the line, and at game size the eye reads it as a smoother curve.

Use it sparingly. On a 16 pixel sprite, a handful of anti-aliasing pixels is enough. Too much makes the sprite look blurry, which is the opposite of what you wanted, and it also breaks down when the sprite moves over a background of a different colour. A common rule is to skip anti-aliasing on the outer edge of sprites entirely and use it only inside them, where you know what colour sits next to the line.

Step 7: test it in context

A sprite that looks good on a transparent checkerboard can disappear on your actual background. Before polishing, drop it into a mock scene: a strip of ground tiles, a sky colour, maybe a second character. Check three things:

• Does it still read at 1x scale?
• Does the outline separate it from the ground and sky?
• Do the darkest values of the sprite clash with the darkest values of the background?

If the character sinks into the scene, the usual fixes are to raise the contrast on the character, lower the contrast of the background, or desaturate the background a little. Characters should usually be the most contrasty thing on screen, because that is where the player looks.

Step 8: export at the native size and scale by integers

This is where a lot of good art gets ruined. Export your sprites at their native size, one pixel of art to one pixel of image, as PNG. PNG is lossless and keeps transparency. Never save pixel art as JPEG: the compression smears colours and introduces faint blocks around every edge.

Then let the game do the scaling, and make sure it scales by whole numbers with nearest neighbour filtering. If an engine draws a 16 pixel sprite at 2.5x, some art pixels become two screen pixels wide and some become three, and the sprite shimmers as it moves. If the texture uses linear filtering, every edge blurs.

In engine terms, that usually means two settings: the texture sampler uses nearest filtering, and the camera or render target uses an integer scale. Here is a tiny helper for picking the largest whole scale that fits the window:

/// Largest integer scale at which the internal resolution fits the window.
fn integer_scale(window: (u32, u32), internal: (u32, u32)) -> u32 {
    let sx = window.0 / internal.0;
    let sy = window.1 / internal.1;
    sx.min(sy).max(1)
}

fn main() {
    // 1920x1080 window, 320x180 art: scale 6, no leftover border.
    assert_eq!(integer_scale((1920, 1080), (320, 180)), 6);
    // 1366x768 laptop: scale 4, with some border left over.
    assert_eq!(integer_scale((1366, 768), (320, 180)), 4);
}

Integer division throws away the remainder, which is what we want here: the leftover space becomes a border, usually filled with a dark colour, rather than a stretched image. On the 1366 by 768 example, the game image is 1280 by 720 and the remaining strip sits around it. Players tend to accept a border far more readily than a blurry or shimmering picture.

How you set nearest filtering depends on the engine or graphics API, so check its documentation for the sampler or texture filter option. In wgpu-style APIs it is a filter mode on the sampler; in higher level engines it is often a per-texture or project-wide import setting. The graphics section covers samplers and render targets in more depth.

Sprite sheet layout that engines like

When you have more than one frame, pack them into a sprite sheet. Keep it boring and regular: every frame in a grid cell of the same size, no padding tricks, frames in reading order. A layout for a small character might look like this:

sheet: 128 x 64 pixels, cells of 16 x 16

row 0: idle   frames 0 to 3   (x = 0, 16, 32, 48)
row 1: walk   frames 0 to 7   (x = 0 to 112, step 16)
row 2: jump   frames 0 to 2
row 3: hurt   frames 0 to 1

The code to find a frame is then simple arithmetic: column times cell width, row times cell height. If you later find that neighbouring frames bleed into each other at the edges when scaled, add one pixel of transparent padding around each cell and adjust the arithmetic. Doing that from the start is not a bad idea either.

Questions people ask

Do I need a drawing tablet?

No. A mouse is fine, and many pixel artists prefer it because pixel art is placing single squares, not drawing long strokes. A tablet helps with rough sketching, but it is optional.

How many colours should a sprite use?

For a 16 by 16 character, somewhere between 4 and 10 is typical, including the outline. You can always add one, but it is much harder to take colours away once the sprite depends on them.

Should I start at 32 by 32 to get more detail?

Detail is exactly what makes larger sprites slower and harder. Starting at 16 teaches you to choose what matters. Move up once a 16 pixel sprite feels comfortable.

Can I scale pixel art by 1.5?

You can, but it will look uneven, because half the pixels become one screen pixel and the other half become two. Keep scales whole and use a border for the leftover space.

A first exercise

Draw one object you can see from your desk at 16 by 16, with a palette of 6 colours: a mug, a plant, a pair of headphones. Spend no more than an hour. Then draw the same object again the next day without looking at the first version, and put the two side by side at 1x. The second one is almost always better, and seeing exactly why is how pixel art improves. When you want more practice ideas, the 2D craft section collects pieces on sprites, tiles and animation.