What's in the pack

• Every frame is 32 × 32 pixels on a transparent background, with no margin or spacing between frames. The art is at most 25 pixels across and centered, so a pivot in the middle of the frame works for all three, and nothing touches the frame's edge.
• The combined sheet has all 22 frames in one row — coin, then gem, then heart — and a TexturePacker JSON (hash) file. Its frames are named coin_00.png to coin_07.png, gem_00.png to gem_07.png and heart_00.png to heart_05.png, each with a centered pivot, and three animation tags list the ranges: coin 0–7, gem 8–15, heart 16–21.
• The whole pack uses 22 colors.

License: CC0

All files are released under CC0 1.0, a public domain dedication. You may copy, change and ship them in any project, free or commercial, "all without asking permission". No credit is required. The deed adds two notes worth knowing: the work comes with no warranties, and you shouldn't suggest that the author endorses your project.

The coin, gem and heart are also part of the Pickups Pack, together with a key, a star, a potion, a treasure chest, a shield, a lightning bolt and an extra-life orb in the same style, each at 16 and 32 px.

How the animations were designed

Three pickups in one game should look like a set, and each should be recognizable in a fraction of a second. Three rules did most of the work.

One light, one outline. All three are lit from the top-left: highlights sit on the upper-left, shadows on the lower-right. Each has a one-pixel outline in a dark version of its own hue — brown for the coin, deep indigo for the gem, wine for the heart — instead of black, which separates the sprite from the background without making it look heavy.

Hue-shifted ramps. Each material is a ramp from dark to light whose hue rotates as it brightens: the coin from 30° (brown) to 50° (pale yellow), the gem from 244° (indigo) to 188° (pale cyan), the heart from 332° (wine) through red to 25° (warm white). Limited Color Palettes for Pixel Art explains why that reads better than darkening one color.

Shapes first. A round coin, a faceted gem and a heart are different even as flat silhouettes, so a player can tell them apart at 1× before any color registers. Inside each sprite, facets and shading are separated by value rather than by internal lines, which keeps 22 pixels from looking busy.

The coin: a turn that reads as rotation

The coin is the one from How to Find the Frame Size of a Sprite Sheet. Its eight frames show half a turn: face-on, edge-on at frame 4, face-on again. Because both faces are drawn alike, the loop looks like a continuous spin. Its width across the eight frames is 22, 21, 17, 10, 4, 10, 17 and 21 pixels — barely changing near face-on and collapsing quickly toward the edge, the way a real turning disc does. Evenly shrinking widths would look like squashing instead of turning. The rim shows on one side as the coin turns away and on the other as it turns back.

The gem: the light moves, not the gem

A gem that bobs or rotates competes with everything else on screen; a gem that catches the light only now and then draws the eye without noise. So the gem never moves. In frames 1 to 4, a diagonal band of light sweeps from its top-left corner to its bottom-right, brightening the pixels it crosses by up to two steps of the ramp. In frames 5 to 7, a four-pointed sparkle appears on the corner where the light hits first, grows and fades.

The timing matters more than the drawing. Played at an even 10 fps, the shine repeats every 0.8 seconds and reads as flicker. Held on frame 0 for 0.6 to 1 second, it becomes an event. Most engines can hold a single frame — see How Fast Should Pixel Art Animate? for each engine's setting.

The heart: a beat, not a breath

The heart has six frames but only four drawings, 19, 21, 23 and 25 pixels wide. At rest it's 21. On frame 1 it jumps straight to 25 — the beat — then eases back through 23 and 21, dips to 19 and settles at 21 again. Rising in one frame and falling over three is what makes it feel like a thump rather than a slow breath. Frames 5 and 0 are the same drawing, a short hold built into the strip. At 10 fps one beat takes 0.6 seconds, 100 beats per minute; holding frame 0 for 0.3 seconds slows it to 0.8 seconds, 75 per minute.

Each size is drawn as its own shape, not scaled from one heart: enlarging a 21-pixel heart to 25 is a factor of about 1.19, and scaling by fractions makes some pixels wider than others. All four sizes have odd widths and share a center column, so the heart grows evenly and never shifts sideways.

Use them in Godot 4

1. Make sure textures use Nearest filtering (Project Settings → Rendering → Textures → Canvas Textures → Default Texture Filter), or the pixels will blur.
2. Add an AnimatedSprite2D, and in its SpriteFrames property select New SpriteFrames.
3. In the SpriteFrames panel, click Add frames from a Sprite Sheet, open a strip, set Horizontal to 8 (6 for the heart) and Vertical to 1, select all frames and add them.
4. Set Speed (FPS) to 10, then start the animation with the node's Autoplay property (the animation to play when the scene loads) or from code:

$Coin.play("default") # Coin is the AnimatedSprite2D node

These steps follow Godot's own 2D sprite animation tutorial. To skip them, load the frames into SpritePilot and download a Godot 4 SpriteFrames (.tres) file from Export & Download instead. The Godot 4 sprite animation article covers per-frame durations, which give the gem its hold.

Use them in Unity

1. Select a strip and set Texture Type to Sprite (2D and UI), Sprite Mode to Multiple, Filter Mode to Point (no filter) and Compression to None, then click Apply.
2. Open the Sprite Editor, choose Slice, set the type to Grid By Cell Count with 8 columns (6 for the heart) and 1 row, click Slice, then Apply.
3. Select the sliced frames in the Project window and drag them into the Scene. Unity's sprite animation tutorial describes how this creates an Animation Clip and adds an Animator for you.

Timing and holds in Unity's Animation window are covered in the Unity sprite animation article.

Use them in Phaser

Load a strip as a sprite sheet, or the combined sheet as an atlas — Phaser's loader accepts TexturePacker's JSON Hash and JSON Array formats:

// in preload()
this.load.spritesheet('gem', 'gem-shine-strip.png', { frameWidth: 32, frameHeight: 32 })
this.load.atlas('pickups', 'sprite-sheet.png', 'sprite-sheet.json')

// in create()
const shine = this.anims.generateFrameNumbers('gem', { start: 0, end: 7 })
shine[0].duration = 900 // hold the resting frame for 0.9 s
this.anims.create({ key: 'gem-shine', frames: shine, frameRate: 10, repeat: -1 })

this.anims.create({
  key: 'heart-beat',
  frames: this.anims.generateFrameNames('pickups', { prefix: 'heart_', start: 0, end: 5, zeroPad: 2, suffix: '.png' }),
  frameRate: 10,
  repeat: -1,
})

this.add.sprite(100, 90, 'gem').play('gem-shine')
this.add.sprite(140, 90, 'pickups', 'heart_00.png').play('heart-beat')

A frame's duration, in milliseconds, replaces the frame rate for that one frame. Keep pixelArt: true in the game config so the sprites stay sharp. More options are in Phaser sprite sheets and atlases.

How the atlas was made

The combined sheet and its JSON were exported by SpritePilot, and you can do the same with your own frames:

1. The 22 frames were laid out in an 8 × 3 grid and cut with Grid Slice in Sprite Detection: 8 columns, 3 rows. Skip empty (fully transparent) cells dropped the two empty cells at the end of the heart row, leaving 22 sprites.
2. In Export & Download: Horizontal Strip layout, Trim transparency off, Padding 0, Extrude 0, TexturePacker metadata. The frames were renamed under Rename & Reorder Sprites — those names go into the JSON — and the three ranges were added under Animation Tags.
3. Download Sprite Sheet saved sprite-sheet.png and sprite-sheet.json. Compared with the three strips placed side by side, the exported sheet matched pixel for pixel.

To try other speeds before you commit, load any strip into the Sprite Player and drag the FPS slider while it plays; everything runs in your browser.

The size of a sheet is decided before you convert, by two numbers you choose: how many frames and how big each one is. The file size on disk then depends on what's in the frames. Here is the math, four ways to shrink a sheet, and what they did to real clips in SpritePilot.

The math: frames × frame size × 4 bytes

• Frames = clip length × sampling rate. A 3-second clip sampled at 10 frames per second gives 30 frames.
• Pixels = frames × frame width × frame height.
• Memory = pixels × 4 bytes, one each for red, green, blue and alpha.

Those 4 bytes are what an image costs once decoded, whatever its file size: a browser's ImageData holds four values per pixel, and Unity lists uncompressed RGBA textures at 32 bits per pixel. A sheet is stored on disk as a compressed PNG, but it's drawn from memory.

Worked through for that 3-second 1080p clip:

Halving the sampling rate halves the memory. Halving the frame width and height quarters it.

Four ways to shrink a sheet

1. Frame size. The strongest lever, because it works on both dimensions: 25% of the size is one sixteenth of the pixels. Pick the size the sprite will actually be drawn at in the game; anything bigger is memory the player never sees. For a screen recording of pixel art, choose the size that undoes the upscaling. A 1080p recording of a 480 × 270 pixel-art scene, converted at 25%, came back at its original resolution: all but one of its 3,888,000 pixels were within 6% of the original color, and the sheet had a ninth of the pixels of the 75% size that Auto suggested.

2. Sampling rate. Game animations rarely need the video's full frame rate; 8 to 12 frames per second is a common range for sprites (see How Fast Should Pixel Art Animate?). Never sample faster than the video itself: a 10 fps test clip sampled at 30 fps gave 60 frames, but only 20 different pictures, each repeated three times.

3. Clip length. Convert the one loop you need, not the whole recording. SpritePilot samples the entire clip, up to 300 frames, so trim the video first.

4. Cropping. Most video frames are mostly background. Cutting the frame down to the subject before converting keeps its full resolution while dropping everything around it. This FFmpeg command keeps 1.5 seconds starting at 0.6 s and crops a 960 × 960 square whose top-left corner is at x 440, y 60:

ffmpeg -ss 0.6 -t 1.5 -i input.mp4 -vf "crop=960:960:440:60" -an clip.mp4

Any video editor can do the same. Here's what these settings did to a 3-second 1080p clip of camera-like footage, all measured in SpritePilot's Video → Sprite Sheet:

The cropped clip keeps the subject at full resolution and still needs less than half the memory of the full frame at 75%.

Sizes engines can actually load

SpritePilot's converters won't save a sheet wider or taller than 8192 pixels, because many engines and GPUs can't load bigger textures. Its video converter also refuses to extract more frame pixels than one 8192 × 8192 sheet holds, about 268 MB, and Auto frame size picks the largest size at which your frames fit:

8192 is a ceiling, not a target. Godot's importing images documentation says mobile and web platforms "usually can't display textures larger than 4096×4096", and Unity scales any texture larger than its import Max Size down when it imports it. If you target phones or browsers, keep sheets at 4096 or below, or split the animation over several sheets. Sprite Sheet Size Limits covers texture size limits in more depth.

Why the PNG size depends on the picture

Memory follows the pixel count, but the PNG file doesn't. Here are three clips with the same length, resolution and settings, so the same 7200 × 4860 sheet:

PNG is lossless. As the PNG specification describes, it filters each row of pixels and then compresses the result with deflate, which works by finding repetition. Flat colors and transparent areas are almost pure repetition, so they nearly vanish. Gradients and grain never repeat exactly, so nearly every pixel costs bytes, and a lossless format has to keep all of them. That's why the camera-like clip is 100 times larger on disk than the test pattern while needing exactly the same memory.

Two practical consequences. A small PNG doesn't mean a light sheet: check width × height × 4. And for camera footage, shrinking the frame size cuts both numbers; in the table, 25% took the PNG from 68.8 MB to 7.1 MB. The sheets in these tests were all 32-bit RGBA PNGs, even from video, which has no transparency. For when a lossy format makes sense instead, see PNG, WebP or JPG for Sprites.

GIFs: the frames are already chosen

A GIF has its frame count and frame size baked in, so GIF → Sprite Sheet has no sampling rate or frame size to choose. It decodes up to 300 frames at the GIF's own size and keeps each frame's delay in the JSON. The levers are the column count, and editing the GIF itself before you convert.

The column count matters more than it looks. An 8-frame, 64 × 64 GIF gives a 3 × 3 grid by default, 192 × 192 pixels with one empty cell; 4 columns make a 256 × 128 sheet with none, 11% less memory. Pick a column count that divides the frame count when the sheet stays under the size limit.

Don't be surprised if the PNG is larger than the GIF. That GIF is 2,627 bytes and the sheet 6,272. A GIF stores each pixel as an index into a table of at most 256 colors, while the sheet stores full RGBA. Transparent backgrounds still compress well, and if the frames have empty borders, sending them to Export & Download and trimming the transparent pixels shrinks the sheet further.

A checklist before you convert

1. Cut the clip to the loop you need, and crop it to the subject.
2. Sample at 8–12 fps, and never faster than the video's own frame rate.
3. Choose the frame size the sprite is drawn at in the game.
4. Estimate the memory: frames × width × height × 4 bytes.
5. Keep sheets at 4096 px or less for phones and browsers; SpritePilot stops at 8192.
6. Judge the PNG by the content: flat art compresses well, footage doesn't.

SpritePilot's converters run in your browser, so nothing is uploaded, and the video converter's plan line shows the frame count, frame size and sheet size before you extract a single frame. For a walkthrough of the controls, see How to Convert a Video to a Sprite Sheet.

What onion skinning shows

Onion skinning displays one or more neighboring frames faintly behind the frame you're editing. The name comes from traditional animation, where frames were drawn on thin, translucent onionskin paper over a light, so the animator could see the drawings underneath (Wikipedia).

The ghost answers three questions while you draw:

• Position: where each part was on the previous frame.
• Spacing: how far it moved since then. Gaps that grow mean speeding up; gaps that shrink mean slowing down.
• Volume: whether the shape is still the same size.

It does not tell you timing, how long each frame stays on screen. For that you have to play the animation.

SpritePilot's onion skin, exactly

In SpritePilot's Pixel Art Editor, the ghost button in the toolbar turns onion skin on and off:

Exactly what it does:

• It shows the previous frame only, at 35% opacity, in its own colors. There's no tint, so a faded yellow can look olive against the checkerboard.
• The ghost sits under the current frame: wherever you've drawn a pixel, the pixel hides the ghost.
• Frame 1 has no ghost. The editor doesn't wrap around to show the last frame under the first.
• The ghost is display only. It is never saved into a frame or an export, the eyedropper ignores it, and the fill tool doesn't treat it as a boundary: filling inside a ghost outline fills every connected empty pixel of the frame.
• The setting is remembered for your next visit, like the editor's other options.

Other editors offer more. In Aseprite, for example, F3 toggles onion skinning, and the timeline's configuration sets how many previous and next frames to show and can tint them red and blue (Aseprite docs). The workflow below works with either.

Draw the keys first, then the frames between

Onion skin is most useful when you draw the important poses first and fill in the rest, instead of drawing frame after frame from the start and hoping the end lands in the right place:

1. Draw the key poses. For the pendulum these are the two ends of the swing: frame 1 at 34° to the right and frame 5 at 34° to the left. For a walk they're the contact poses; for a jump, the crouch, the peak and the landing.
2. Add the breakdowns, the main drawings between the keys. Here that's frame 3, hanging straight down, halfway through the swing.
3. Fill the in-betweens. Select a key, press Duplicate frame to copy it in after itself, and move only what changes, with the previous frame showing underneath.
4. Flip through the frames with onion skin on and watch how each one relates to the one before it:

An in-between depends on the frames on both sides, but SpritePilot only ghosts the previous one. To check the next frame, use the move buttons above the frame strip. Say frame 2 sits between frames 1 and 3: select frame 2 and press Move frame right. Frames 2 and 3 swap places, your frame stays selected, and frame 3 is now the ghost underneath. Compare, then press Move frame left to put it back. Adding, duplicating, moving or deleting a frame clears the undo history, so finish a correction before you rearrange.

Check arcs and spacing

Two things often go wrong between key poses, and the ghost shows both.

Arcs. Most natural motion follows curved paths, a point Disney's animation principles make explicitly (twelve principles). Arms swing from the shoulder, heads turn on the neck, a pendulum swings from its pivot. The tempting in-between is the one halfway along the straight line between the two keys. It's easy to place and it's wrong:

With the two keys ghosted, the straight-line in-between puts the bob 22.4 pixels from the pivot instead of 27, and the rod visibly shrinks in the middle of every swing. On the arc, the rod keeps its length. The same mistake shortens arms and legs in character animation. Before drawing an in-between, find the pivot, such as the shoulder for an arm or the hip for a leg, and keep the distance from it.

Spacing. The right-hand panel shows where the bob sits in frames 1 to 5. The gaps between them are 4.7, 11.2, 11.2 and 4.7 pixels: small at the ends, where a pendulum slows down to turn, and large through the middle, where it's fastest. The angles come from 34° × cos(k × 45°), with k running from 0 to 7 for frames 1 to 8, which produces exactly that easing. With onion skin on you can see the gap to the previous frame directly, so uneven spacing is easy to spot: a gap that is suddenly bigger or smaller than its neighbors is a lurch in the motion.

Mistakes that onion skinning can cause

• Tracing the ghost. Copying the previous frame's outline and nudging it tends to give stiff motion, and small tracing differences from frame to frame make edges flicker. Use the ghost to place things, then draw the shape the way it should look in this pose.
• Drifting volume. If every frame is drawn only against the one before it, a one-pixel error on each frame adds up: by frame 8 the head can be two pixels smaller than on frame 1. Count the pixels of something that shouldn't change, such as head width or the size of a ball, on the first and last frames.
• Mistaking the ghost for real pixels. At 35% the ghost can look like part of the drawing. Toggle onion skin off now and then to see what's actually on the frame.
• Judging timing from the ghost. Even spacing on the canvas can still play too fast or too slow. Press Play in the Preview panel and adjust the speed. For choosing a frame rate, see How Fast Should Pixel Art Animate?

Try it

Open the Pixel Art Editor, start a new drawing with the 32×32 button (or type 48 into W and H for more room), and animate something simple with an arc: a pendulum, a waving arm or a bouncing ball. Draw the two ends of the motion first, add the middle drawing between them, then fill the rest with onion skin on. Play the preview at 8 to 12 FPS and fix whatever lurches. The drawing saves itself in your browser, and Download GIF or Download Sheet PNG exports it. The drawing guide covers the editor's tools, and the same approach applies to walks (How Many Frames Does a Walk Cycle Need?) and bounces (Squash and Stretch for Sprite Animation).

Why a small palette makes better pixel art

A palette isn't a restriction you put up with. It does three jobs for you:

• Consistency. Every sprite drawn from the same palette shares the same skin tones, the same shadow color and the same highlight. Characters drawn weeks apart, or by different people, still look like one game.
• Readability. A 32 × 32 sprite is read by its shapes, and shapes come from clear steps between colors. Ten nearly identical reds don't add detail at that size; they make edges soft and look like noise.
• Speed. Shading becomes "pick the next darker swatch" instead of nudging three sliders until something looks right.

Some platforms make the limit part of their identity. The PICO-8 fantasy console's official manual gives it a fixed palette of 16 colors, a limit its games are designed around.

How many colors do you need? A well-built palette of 16 to 32 colors can cover a game's characters, tiles and interface. A single sprite uses far fewer: the coin in this article uses 8.

Ramps: the part of a palette you actually shade with

A ramp is a run of colors for one material, from its deepest shadow to its brightest highlight. Shading a sprite means moving up and down a ramp: the side facing the light gets the lighter steps, the side facing away gets the darker ones, and the outline is often the darkest step of all.

Good palettes are built out of ramps, even when they don't look like it. Here is DawnBringer's 32-color palette, DB32, which SpritePilot's Pixel Art Editor loads by default:

Read the first row from left to right and it works as a ramp for skin, wood or earth. The interesting part is the hue: the darkest steps aren't dark orange, they are dark blue-violet and plum. That isn't a quirk; it's a technique called hue shifting.

The full palette, ready to paste into any editor:

#000000 #222034 #45283c #663931 #8f563b #df7126 #d9a066 #eec39a
#fbf236 #99e550 #6abe30 #37946e #4b692f #524b24 #323c39 #3f3f74
#306082 #5b6ee1 #639bff #5fcde4 #cbdbfc #ffffff #9badb7 #847e87
#696a6a #595652 #76428a #ac3232 #d95763 #d77bba #8f974a #8a6f30

Hue shifting: shadows aren't just darker

The obvious way to build a ramp is to keep one hue and change only the lightness. It works, but it tends to look flat and a little muddy. The usual alternative is hue shifting: as a color gets darker, rotate its hue toward blue or purple; as it gets lighter, rotate it toward yellow.

The left sphere is fine; the right one looks lit. Its shadows lean toward teal, as if they were filled with cool light from the sky, and its highlights lean toward a warm yellow, like sunlight.

There's no fixed amount to shift. The coin's gold moves only 20° from outline to highlight (30° to 50°); the green ramp above moves about 20° per step; DB32's first row swings more than 100° across its three darkest steps. Small shifts read as a richer version of one color; large ones read as a deliberate stylistic choice. Both are fine; a ramp whose hue jumps around without a direction is not.

Check the values with a grayscale copy

Hue and saturation give a sprite its character, but value — how light or dark each color is — is what makes it readable. The quickest check is to look at it in grayscale: each step of a ramp should be clearly lighter than the one before it, and the outline, shadow, base and highlight should stay apart.

Two things stand out:

• "Gold, one hue" keeps the original's lightness, so its grayscale copy is nearly identical. In color, though, its dark steps turn olive and the coin looks duller. Hue shifting is about richness, not readability.
• "Gold, values too close" looks acceptable in color, because the hues still differ. In grayscale the outline, rim and face merge, and that is how it will read at small sizes and on a busy background.

Any editor can desaturate a copy of your sprite. In a browser, add filter: grayscale(1) to the image in the developer tools; it's what made the grayscale row above, and MDN documents the function. Also look at the sprite at its real size, 1×, on the background it will appear on.

Palettes worth starting from

You don't have to invent a palette to get these benefits. Three well-known starting points:

• DB32 — the 32 colors above, by the pixel artist DawnBringer. Wide enough for a whole game, and built from ramps.
• DB16 — DawnBringer's 16-color palette, for when 32 colors are more than you need.
• PICO-8 — 16 fixed colors, listed in the manual by name, from black and dark blue to pink and peach. A good exercise in doing a lot with a little.

Lospec's palette list is a database of pixel-art palettes that you can filter by number of colors, and it offers each palette as a PNG image, which is exactly what the import below needs.

Build your own ramp

When no palette fits, build ramps one material at a time:

1. Pick the base color, the one most of the material will be. For the coin that's the face, #f6bd3a.
2. Add two or three darker steps and one or two lighter ones. Space them evenly in lightness; the green ramps above step 12 to 16 points of HSL lightness at a time.
3. Rotate the hue a little at every step — toward blue or purple going darker, toward yellow going lighter.
4. Check it in grayscale. Fix any step that merges with its neighbor before you shade anything with it.
5. Share colors between ramps. One dark purple can outline the wood, the leaves and the stone, which keeps the whole palette small.

Most materials need 3 to 6 steps. A sprite with a single material, like the coin, can afford a longer ramp: its gold has 8.

Import a palette into SpritePilot's Pixel Art Editor

In the Pixel Art Editor, the palette panel shows DB32 until you click Import and choose an image. What happens next matters for picking the right image:

• The editor reads the image's pixels as they are, with no blending, and skips pixels that are more than half transparent.
• It counts how often each exact color appears and keeps the 32 most used, most used first. Colors used equally keep the order in which they first appear: left to right, top to bottom.
• Images bigger than 512 px on their longest side are reduced first (again without blending), so small palette images are read pixel for pixel.

So the best source is a palette image with one swatch per color, all the same size — such as a palette downloaded as a PNG, or this 16-color example with the gold, silver, emerald and ruby ramps used in these articles (free to use). A photo or an anti-aliased painting is a poor source: it has thousands of slightly different colors, and the 32 most common are usually near-duplicates from its largest areas.

The import changes the swatches you pick from, not what you've already drawn. Reset brings DB32 back, and the editor remembers your palette in this browser for next time. You can also type any hex value into the Color field next to the color picker.

In short

• Draw from a fixed palette: 16 to 32 colors for a game, 3 to 6 steps per material.
• Build ramps that rotate the hue — toward blue or purple in the shadows, toward yellow in the light.
• Check every ramp in grayscale; value is what makes a small sprite readable.
• Start from DB32, DB16 or PICO-8 if you don't want to build your own.
• To use a palette in SpritePilot, import an image with one equal-sized swatch per color; it reads up to 32 colors.

Want to see a ramp in motion? The free animated pickup sprites use three hue-shifted ramps — gold, blue and red — and list every color they use.

To put numbers on it, four sheets were saved in all four encodings with Chrome's built-in encoders (the ones SpritePilot's export uses in Chrome), then decoded again and compared pixel by pixel.

What each format can and can't do

Lossless means you get every pixel back exactly as it was. Lossy means the encoder throws away detail it expects you won't notice. That works on photos, where neighboring pixels blend into each other anyway. It fails on pixel art, where every hard edge and every lone pixel is deliberate.

WebP does both. Google's WebP page puts lossless WebP at about 26% smaller than PNG, and notes that lossy WebP can keep transparency too. Browser support is no longer a worry: MDN's image format guide lists WebP in every current browser, with one catch on Macs, where Safari needs version 14 or later running on macOS 11 Big Sur or later. One limit worth knowing for big sheets: a WebP image can't be wider or taller than 16,383 pixels.

What JPG and lossy WebP do to pixel art

Look at the red and yellow flower on the grass tile. JPG can store color at a lower resolution than brightness, and Chrome's encoder does: at its default quality of 0.92 it keeps one color sample for every 2 × 2 pixels, so a flower drawn with single pixels turns into a brownish smudge. The rest of the compression works on blocks of 8 × 8 pixels and rounds away fine detail inside them, so green leaks into the water along tile edges and the stone lines go soft. Lossy WebP has the same weakness: Google's WebP FAQ says lossy mode works only with 4:2:0 color, the same half-resolution color Chrome's JPG uses.

Transparency is the other problem. JPG has none, so every transparent pixel must become a solid color. SpritePilot fills them with white before it saves a JPG; Chrome's encoder on its own turns them black. Either way, the coin gets a box around it. Lossy WebP kept the coin's transparency intact in the test, but still changed the color of 2,213 of its 8,192 pixels.

And none of that damage buys a smaller file. For the coin, the JPG was 2.8 times the size of the PNG.

Measured file sizes

The four sheets: the 8-frame coin strip, the 8-tile meadow tileset, SpritePilot's bouncing-ball sample, and a 1024 × 512 sheet of a smoothly shaded orb, standing in for painted, high-resolution art. Sizes are in bytes. Lossy WebP used Chrome's default quality of 0.8, and JPG its default of 0.92.

What the numbers say:

• Lossless WebP beat PNG on every sheet, by 26% to 62%, and both gave back every pixel exactly.
• On the three hard-edged sheets, lossy formats don't pay. JPG came out bigger than the PNG every time, up to 2.8 times. Lossy WebP was bigger on the coin and 16–20% smaller on the other two, while changing 2,031 of the tileset's 2,048 pixels. Hard edges and flat colors are what PNG and lossless WebP compress best, and exactly what lossy encoders struggle with.
• On smooth, painted art, lossy formats win big. The orb went from 482 KB as PNG to 86 KB as lossy WebP and 83 KB as JPG, about a sixth. Only the WebP kept the transparent background.
• The encoder matters as much as the format. Chrome's encoders favor speed; Chromium's source code sets its PNG encoder to a low compression level. ImageMagick with its strongest PNG settings saved the coin in 915 bytes, half of Chrome's PNG, and Google's cwebp tool with -z 9 made a 558-byte lossless WebP. Going the other way, re-saving the ball sample through Chrome grew it from 918 to 3,092 bytes. All of those files are lossless, so run your final web assets through an optimizer.

In memory, every format is the same size

The file format decides the download and the disk space, not the memory. To draw a sprite, the GPU needs plain pixels, so the image is decoded first, and an uncompressed texture costs 4 bytes per pixel: red, green, blue and alpha.

Memory = width × height × 4 bytes.

• Coin strip: 256 × 32 × 4 = 32,768 bytes, for a file of 1,274 to 5,203 bytes.
• Shaded orb: 1024 × 512 × 4 = 2,097,152 bytes (2 MiB), whether it arrived as an 83 KB JPG or a 482 KB PNG.

The engines say the same. Unity's manual explains that GPUs don't use formats like JPEG or PNG at runtime; when you import a texture, the Editor picks a GPU format for each build platform. Godot's import documentation says of its Lossy mode: "Video memory usage isn't decreased by this mode." Texture memory only goes down with a smaller sheet or a GPU format that uses fewer bits per pixel, and those formats usually spoil pixel art. How Big Can a Sprite Sheet Be? has the memory math for whole atlases.

Which formats your engine accepts

• Unity 6 imports BMP, EXR, GIF, HDR, IFF, JPG, PICT, PNG, PSD, TGA and TIFF. WebP isn't on the list, so give Unity PNGs. Unity converts every texture to its own GPU format anyway, so a PNG source costs nothing in the game, while a JPG source would bring its artifacts along.
• Godot 4 imports PNG, JPEG and WebP, among others. With the default Lossless compression, which the Godot docs recommend for pixel art, the imported texture is stored as lossless WebP or PNG whatever you started from. PNG and WebP both work.
• Phaser loads images through the browser: its loader turns each downloaded file into a regular browser image. So it reads anything the browser can display, WebP included. The same goes for CSS and canvas animation.

For engines that re-encode on import, use PNG and stop worrying. For games that run in a browser, the file you ship is the file players download, and lossless WebP is the smaller choice.

What SpritePilot's export writes

Export & Download offers all three formats for the sheet and for the ZIP of separate sprites:

• PNG comes from your browser's encoder: lossless, though not the smallest possible file.
• WebP is saved at quality 1, which Chrome and other Chromium-based browsers encode as lossless WebP. In the test, every exported pixel came back identical. If your browser can't write WebP from a canvas (MDN's compatibility data lists Safari among them), the WebP button is disabled.
• JPG gets a white background where the sprites were transparent, then the browser's default quality: 0.92 in Chrome.

The other tools, including the Sheet Maker, the GIF and video converters and the Pixel Art Editor, save their sheets as PNG. For what each metadata file contains, see Sprite Sheet Export Formats Explained.

In short

• Pixel art, any engine: PNG. For the web, lossless WebP is smaller, by 26–62% on these sheets.
• Unity: PNG; it can't import WebP and re-encodes everything anyway.
• Large painted sprites on the web: lossy WebP, checked at 100% zoom. JPG only if nothing in the sheet is transparent.
• Never JPG for pixel art: bigger files, smeared colors, no transparency.
• Optimize final files: a good encoder halved some of these PNGs without changing a pixel.
• Memory is width × height × 4 bytes no matter which format the sheet came from.

Why old sprites sit on magenta or white

Before every format and engine handled transparency per pixel, a common trick was a color key: one color that means "transparent". It still exists in libraries today. pygame's Surface.set_colorkey, for example, makes "any pixels that have the same color as the colorkey" transparent when the surface is drawn — the same color, exactly.

Magenta, (255, 0, 255), is the classic key because it almost never appears in the art itself. White backgrounds turn up in sheets exported for print or the web, and in screenshots. Either way, the job is to turn that one color into real transparency, and for crisp pixel art that is simple. The trouble starts with smooth edges.

Where the halo comes from

A smooth, anti-aliased edge is drawn with pixels that are only partly covered by the sprite. Their color is a mix of the sprite and whatever was behind it — the standard alpha compositing formula:

color = coverage × sprite color + (1 − coverage) × background color

Take an edge pixel that is 38% dark outline, (32, 32, 32), and 62% background. On magenta it was saved as 0.38 × 32 + 0.62 × 255 = 170 for red and blue, and 0.38 × 32 + 0.62 × 0 = 12 for green: (170, 12, 170), a purple pixel. On white, the same pixel is (170, 170, 170), a light gray.

A simple key removes pixels that are close to the background color and keeps everything else, fully opaque. (170, 12, 170) is 121 RGB units away from magenta, so it stays — as a solid purple pixel around a sprite that no longer sits on magenta.

To measure it, we used two test sheets: eight anti-aliased sprites flattened onto magenta and onto white, so the correct transparent result is known exactly. The original sprites have 832 partly transparent edge pixels. A hard key — Remove Background with soft edges switched off — at the default tolerance left 608 of them fully opaque, and 256 of those are more background than sprite. That's the halo you see.

Tolerance is a trade-off, not a fix

The natural reaction is to raise the tolerance. In SpritePilot's Remove Background, a pixel matches the key when its RGB distance from the key color is at most the tolerance × √3, so the default of 30 allows a distance of 52 — about 30 levels in each channel. Here is what higher values did to the magenta sheet, with soft edges switched off:

The halo shrinks, but every edge pixel is still either deleted or kept at full strength. The 38% outline pixel only goes away from a tolerance of 70, and then it disappears completely, so outlines get thinner and more jagged while the pixels that remain keep their tint.

Higher tolerances also start to match the sprites' own colors. The pink sprite, (240, 50, 230), is only 58 units from magenta, so any tolerance from 34 up matches it; the purple one matches from 79 and the red one from 106. Removed everywhere, their bodies vanish:

Edges only, or everywhere?

That bottom row is the second setting that matters. The tool's default, Background touching the edges, starts at every pixel on the border of the image and spreads through matching pixels, like a magic wand clicked all around the edge. Color enclosed by a sprite's outline is never reached, so it stays. The fill moves only up, down, left and right — never diagonally — so it can't slip through the diagonal steps of a one-pixel outline.

That's how white eyes survive on a white sheet:

The tool tells you when it has kept matching pixels — "152 pixels of this color are enclosed inside shapes and were kept" — so you can decide. Switch to This color everywhere only when the background really does show through closed holes, like the middle of a ring or a gap between an arm and a body.

Edge mode protects colors only when something encloses them. A sprite with no outline, whose own edge is close to the key color, can still be eaten from the outside.

What soft edges do

The Soft edges option (on by default) doesn't delete or keep edge pixels; it estimates how much of each one was sprite and rebuilds it:

1. It starts at the kept pixels that touch the removed background and works inward, at most 3 pixels, only through pixels that turn out to be part background. A solid outline stops it, so a sprite's interior is never touched.
2. A pixel whose color carries on into the sprite — a nearly identical neighbor that isn't on the edge — is solid paint and stays as it is.
3. Otherwise it looks within 2 pixels for a stronger sprite color that explains the pixel as a blend of that color and the background, allowing a little for rounding and compression. How far the pixel sits along that blend is its coverage.
4. Coverage of 92% or more counts as solid. Below that, the coverage becomes the pixel's opacity, and the background is subtracted from its color: (pixel − background) ÷ coverage + background.
5. A pixel that no blend explains but that is just outside the tolerance fades from transparent to opaque across a narrow band — that catches JPEG specks.

For the marked pixel above, that gives an opacity of 97 out of 255 (38%) and the color (32, 32, 32): exactly the original. Across the whole magenta sheet, at the default settings, soft edges left no halo pixels; edge opacity was off by 2.4 levels out of 255 on average, and color by about 1. The white sheet came out almost the same: 2.7 and 1.2.

Crisp pixel art is left alone. On a test sheet with one-pixel outlines, diagonal steps, a near-magenta pink sprite and a magenta gem inside every sprite, the default settings reproduced the original transparent sheet pixel for pixel — and kept the 32 gem pixels, which are enclosed. You only need to switch soft edges off if you want every edge pixel kept exactly as it is, partial pixels included.

Soft edges assume one flat background color. Gradients, textures and heavy JPEG noise won't un-mix cleanly, and glows wider than 3 pixels are only partly restored. For photos or complex backgrounds, use the AI background removal in Sprite Detection instead (that one runs on SpritePilot's server).

A second halo: dark edges in the engine

A clean PNG can still show a dark rim in the game. Fully transparent pixels still store a color — in the PNG that Remove Background saves, it's black, (0, 0, 0, 0) — and when an engine scales or moves a sprite with smooth filtering, it can blend that hidden color into the edge. Two fixes:

• For pixel art, use nearest filtering (see Why Lines Appear Between Your Tiles); nothing gets blended.
• For smooth art, let the engine pad the colors. Godot's import option Fix Alpha Border surrounds opaque areas with pixels of their own color and is on by default, according to the documentation; in Unity, Alpha Is Transparency dilates the color channels for the same reason.

A checklist

1. Pick the background from a corner, and check the RGB value the tool shows.
2. Keep Background touching the edges unless background shows through closed holes.
3. Leave the tolerance low (around 30) and let Soft edges handle the fringe; raise it only for noisy backgrounds, and watch the percentage of removed pixels.
4. Check the result zoomed in, on a background unlike the original: dark for a white sheet, light for a magenta one.
5. Read the enclosed-pixels message before you switch to This color everywhere.

The click-by-click version is in How to Remove the Background from a Sprite Sheet. The tool runs entirely in your browser, and Send to Sprite Detection takes the cleaned sheet straight on to be split.

Why scaled pixel art goes blurry

When an image is drawn bigger than it is, the computer has to invent the new pixels. There are two basic ways to do it:

• Smooth (bilinear) scaling blends neighboring pixels according to how close they are. That suits photos, but on pixel art it softens every edge and creates in-between colors that you never drew.
• Nearest-neighbor scaling copies the closest source pixel. Every pixel becomes a solid block and no new colors appear.

Smooth is usually the default: a canvas's imageSmoothingEnabled starts out true, and Phaser smooths until you set pixelArt: true. For pixel art you want nearest-neighbor everywhere — in the browser, in the engine, and in any tool that resizes your files.

Whole-number scales keep every pixel the same size

Nearest-neighbor fixes the blur, not the size. At 2× each source pixel becomes a 2 × 2 block, and at 3× a 3 × 3 block. At 2.5× a pixel can't be two and a half screen pixels wide, so the columns alternate between 3 and 2:

On a sprite, that makes one-pixel outlines thicker in some places than others and turns curves lumpy. When the sprite moves, the wide and narrow columns move across it, so the art seems to wobble. The fix is to scale by whole numbers only — 2×, 3×, 4× — and fill any leftover screen with a border.

That's the appeal of base resolutions like 320 × 180 and 640 × 360: they multiply evenly into common screens.

In the browser: image-rendering: pixelated

For an image on a web page, one CSS property switches the browser to nearest-neighbor:

<img src="coin.png" width="96" height="96" alt="Coin" class="pixel-art">

.pixel-art {
  image-rendering: pixelated;
}

That's a 32-pixel coin shown at exactly 3×. In a test in Chromium, every screen pixel came out identical to its source pixel; without the property the same image had 280 colors. MDN's image-rendering page lists support for pixelated since Chrome 41, Firefox 93 and Safari 10. Don't rely on crisp-edges for the same job: Chrome only added it in version 148, and the Chromium 145 we tested still smoothed it.

The CSS specification allows pixelated to add a little smoothing when the size isn't a whole multiple; Chromium 145 didn't, and drew plain 3- and 2-pixel columns at 2.5×. Either way, a fractional scale can't be both sharp and even.

Watch out for display scaling. CSS pixels aren't screen pixels. On a laptop with display scaling at 125%, window.devicePixelRatio is typically 1.25, so an image drawn at 2× in CSS covers 2.5 screen pixels per source pixel — the uneven pattern again, even though your CSS says 2×. At 150%, the same 2× happens to be an even 3.

In a canvas game: draw small, then scale by whole screen pixels

The reliable way to get crisp pixels in a canvas game is to draw everything at the game's base resolution, then scale the whole canvas up by the largest whole number of screen pixels that fits:

#game {
  image-rendering: pixelated;
}

const GAME_W = 320
const GAME_H = 180
const canvas = document.getElementById('game')
const ctx = canvas.getContext('2d')
canvas.width = GAME_W
canvas.height = GAME_H
ctx.imageSmoothingEnabled = false

// The largest whole-number scale that fits the window, in device pixels
function fit() {
  const dpr = window.devicePixelRatio || 1
  const scale = Math.max(1, Math.floor(Math.min(
    (window.innerWidth * dpr) / GAME_W,
    (window.innerHeight * dpr) / GAME_H,
  )))
  canvas.style.width = (GAME_W * scale) / dpr + 'px'
  canvas.style.height = (GAME_H * scale) / dpr + 'px'
}
window.addEventListener('resize', fit)
fit()

We ran this at device pixel ratios of 1, 1.25, 1.5, 1.75 and 2 and measured the screenshots: every game pixel covered the same number of screen pixels in every case. A version that worked out the scale in CSS pixels instead gave uneven columns at some window sizes: 3 and 2 screen pixels at 125%, 5 and 4 at 150%, 5 and 6 at 175%.

Three details that bite:

• Set imageSmoothingEnabled again after resizing the canvas. The HTML standard resets the context's state whenever the canvas's width or height is set; in our test the property went from false back to true.
• Round positions. With smoothing on, drawing the coin at x = 10.5 blurred it into 18 colors. With smoothing off, Chromium drew it exactly as at x = 11 — but Math.round(x) makes that your choice, not the browser's.
• Draw sprites at 1× inside the small canvas. The canvas scale does the enlarging, once, for everything.

In game engines

The texture filter settings for each engine are covered in Why Lines Appear Between Your Tiles: Nearest in Godot, Point in Unity, pixelArt: true in Phaser. For whole-number scaling:

• Godot 4.2+: Project Settings → Display → Window → Stretch: set Mode to viewport and Scale Mode to integer. The documentation explains that this rounds the scale factor down to a whole number and fills the rest of the window with black bars.
• Unity: add the Pixel Perfect Camera (URP) and set Asset Pixels Per Unit to your sprites' value and Reference Resolution to your base resolution, such as 320 × 180. Unity's manual says it keeps pixel art "crisp and clear at different resolutions, and stable in motion".
• Phaser 3.16+: set the zoom to Phaser.Scale.MAX_ZOOM, which picks the largest whole-number zoom that fits the parent element. It's worked out when the game starts, so call this.scale.setMaxZoom() again when the window changes size.

const config = {
  type: Phaser.AUTO,
  width: 320,
  height: 180,
  pixelArt: true,
  scale: {
    mode: Phaser.Scale.NONE,
    zoom: Phaser.Scale.MAX_ZOOM,
  },
  scene: [GameScene],
}

Scaling down is a different problem

Shrinking pixel art has no good automatic answer. Nearest-neighbor at 50% keeps every other row and column and throws the rest away: on the coin, the one-pixel outline vanished from long stretches of the edge. Smooth shrinking keeps a hint of everything but blurs it, turning the coin's 7 colors into 24.

So:

• If you need a smaller sprite, draw it. By hand you decide which details survive; an algorithm can't tell an eye from a speck.
• If the art was enlarged by a whole number, shrink it by exactly that number. A coin scaled up 3× with nearest-neighbor and back down to a third came out identical to the original, pixel for pixel. It's also the fix for art you received already enlarged, such as a 4× preview image: count how many screen pixels one art pixel covers, scale back to 1×, and let the engine do the enlarging.

Batch-scale sprites in SpritePilot

SpritePilot's Advanced Processing resizes every sprite in your session at once. Load the sprites first — cut a sheet with Grid Slice in Sprite Detection, for example — then choose Scaling Mode → Custom Size, enter the target width and height, and keep Resampling on Pixel art: keep every pixel sharp.

Pixel resampling is nearest-neighbor: every output pixel is a copy of a source pixel. We scaled the eight 32 × 32 coin frames to 96 × 96 and compared them with a perfect 3× enlargement: not one pixel differed. The Smooth option, meant for painted or photographic art, gave the same frame 651 colors. The results are saved as lossless PNG; Apply to Session passes them on to Export & Download, or Download ZIP saves them as files.

Two things to know:

• There's no "scale by 3×" field. You type the target size, so make it a whole multiple of the sprite size — 64, 96 or 128 for a 32-pixel sprite. Uniform and Smart scaling resize every sprite to the size of the smallest or largest one, which is rarely a whole-number factor.
• Leave Edge sharpening and Noise reduction off for pixel art; nearest-neighbor already gives you hard edges, and the tool itself labels noise reduction as not meant for pixel art.

A checklist

1. Nearest-neighbor everywhere: image-rendering: pixelated, imageSmoothingEnabled = false (again after every resize), Nearest or Point filtering in the engine.
2. Whole-number scales, measured in screen pixels — include devicePixelRatio in the math.
3. A base resolution that divides common screens, such as 320 × 180 or 640 × 360.
4. Whole-pixel positions for sprites and the camera.
5. To shrink, redraw — or undo an enlargement by exactly its factor.

A duplicated frame at the seam

The classic hitch is a last frame that is the same as the first. The pose then appears twice in a row, so the motion stops for one frame every cycle:

It tends to sneak in one of three ways: the first frame is copied to the end "to close the loop", a rotation is rendered from 0° to 360° inclusive, or a captured GIF or video ends where it started.

The fix is to make the last frame one normal step before the first. For a full turn in 8 frames, each step is 360° ÷ 8 = 45°, so the frames sit at 0°, 45°, 90° … 315°. The next frame would be 360°, which looks the same as 0°, and that one is frame 1 of the next cycle. The same goes for any loop: if a bob moves 2 pixels per frame, the last frame should be 2 pixels away from the first, not on top of it.

To check a sheet, load it in SpritePilot's Sprite Player and press Home and End to flip between the first and last frames. If they look identical, delete the last one.

Ping-pong: do the end frames repeat?

Ping-pong plays the frames forward, then backward, then forward again. It suits motions that reverse on their own, such as breathing, swaying or a pendulum, and it nearly halves the drawings they need: 8 drawings give a 14-step cycle. Whether it hitches depends on how the turnaround is done:

• Turning without repeating shows frame 8 once, goes straight to 7, and back down to 1 before heading to 2. A full back-and-forth of 8 frames takes 2 × 8 − 2 = 14 steps.
• Appending a reversed copy of all the frames (1–8 followed by 8–1) takes 16 steps and shows frames 8 and 1 twice in a row each, a hitch at both ends.

SpritePilot's Sprite Player does the first. Its Ping-pong option steps 1 → 8, then 7 → 1, then 2 → 8, with each end frame on screen for a single step, and it keeps bouncing whether or not Loop is ticked. Phaser's yoyo option turns around the same way: in Phaser's source, the animation steps from the last frame straight to the one before it, and when it repeats, from the first frame straight to the second.

The trap is exporting. The player's GIF and APNG buttons write the frames once, in sheet order, so the ping-pong isn't in the file. If you need a ping-pong GIF, or an engine that only loops forward, put the return trip in the sheet: frames 1 to 8 followed by 7 to 2, for 14 frames. Adding 8 to 1 instead brings back both doubled frames.

Don't ping-pong motions that only go one way. A spinning coin, a walk, fire or a waterfall played backward is visibly reversed: the coin spins back, the character walks backward.

Spacing across the seam

Even with no duplicated frame, a loop can slow down at the seam. That happens when the spacing, how far things move between frames, changes there.

One-way motion (spinning, walking, scrolling, a flag rippling) should keep the same spacing across the seam as everywhere else. The mistake to avoid is easing a loop as if it were a one-shot animation: slowing into the last frame and out of the first. Played once, that looks natural. Looped, it slows down and speeds up again every cycle.

Back-and-forth motion (hovering, bobbing, breathing) is the opposite: it should slow down, at the top and bottom where it turns around. With even spacing it bounces off the ends like it hit a wall:

A sine curve gives you that easing for free, and it loops cleanly, because the step from the last frame back to the first is the same size as the step after it. This function returns the vertical offsets, in pixels, for each frame of a hover:

// Vertical offsets (in pixels) for a hover loop of `frames` drawings.
// The sine curve slows down at the top and bottom, and the last frame
// leads straight back into the first.
function hoverOffsets(frames, amplitude) {
  const offsets = []
  for (let i = 0; i < frames; i++) {
    offsets.push(Math.round(amplitude * Math.sin((2 * Math.PI * i) / frames)))
  }
  return offsets
}

console.log(hoverOffsets(12, 6)) // [0, 3, 5, 6, 5, 3, 0, -3, -5, -6, -5, -3]

Those are the heights of the eased coin above. The loop runs from i = 0 to frames − 1, never to frames itself, which would duplicate frame 1. The steps between frames are 3, 2 and 1 pixels: large in the middle of the motion, small at the turns, and 3 again across the seam from −3 back to 0.

Holds that look deliberate

A pause isn't always a mistake. A coin that rests face-on for half a second, an idle that holds still before a blink, a breath held at the top: holds give a loop rhythm. The difference between a hold and a hitch is mostly length. One extra frame, 0.1 s at 10 fps, looks like a skipped beat. Five frames' worth, as in the right-hand coin above, looks intended.

There are two ways to make one:

• Per-frame durations in the engine or editor that plays the animation. How Fast Should Pixel Art Animate? shows how in Godot, Phaser, Unity and Aseprite.
• Repeating the frame in the sheet. That works everywhere, and it's the way to preview a hold in the Sprite Player, which shows every frame for the same time.

A loop checklist

Load the sheet in the Sprite Player (no sheet handy? The CC0 coin strip is 8 frames of 32 × 32) and go through these:

1. End, then Home: flip between the last frame and the first. If they're identical, delete the last one.
2. ← and →: step through the frames and note how far things move each time. The jump from the last frame to the first (End, then Home again) should be the same size.
3. Speed: play it slowly, at 2 to 4 FPS, where a hitch is easy to see, then at full speed.
4. Ping-pong: only for motions that reverse. To export it, add the return frames without the ends: 8 frames become 14.
5. Holds: make them long enough to look intended, or remove them.

When it loops cleanly, the GIF and APNG buttons export it as an endlessly looping animation. How to Convert a Sprite Sheet to a GIF explains when to pick which.

This article explains what a pivot is, where to put it, why the wrong one makes sprites jump, and how to set it in Unity, Godot, Phaser and SpritePilot.

What a pivot is

A sprite is a rectangle of pixels, but the game positions it by a single point. That point is the pivot: whatever coordinates you give the object, the pivot lands exactly there. Unity's documentation calls it the point "Unity uses for transformations such as rotation", so it is also what the sprite turns and scales around.

Pivots are usually written as fractions of the frame, from 0 to 1, so they work for any frame size. The same point gets different names and conventions:

Unity counts y upward from the bottom-left corner of the sprite; Phaser and SpritePilot count downward from the top-left. Mixing them up flips the pivot to the character's head.

Where the pivot should go

• Center for anything that spins, scales or has no ground: coins, projectiles, explosions, floating pickups. They rotate around their middle, which is what you want.
• Feet (bottom center) for characters, enemies and props that stand on something. The object's position becomes the point where it touches the ground, so placing it on a platform, snapping it to a tile or sorting it by depth works directly. Unity can sort by it too: set the Sprite Renderer's Sprite Sort Point to Pivot.
• Top-left for UI and anything aligned to a grid, where you think in corners.

For pixel art, make sure the pivot lands on a whole pixel. A centered 25-pixel-wide sprite has its middle at 12.5 pixels, between two pixels, and Godot's documentation notes that centered pixel art can look deformed for exactly that reason. Even frame sizes avoid it.

Why sprites jump between frames

A pivot is defined per frame. When every frame has the same size and the character stands in the same spot in each, any pivot works. Trouble starts when frames differ: an attack frame drawn wider to fit a weapon, or a crouch drawn shorter.

Here the idle frame is 32 × 40 pixels, the cast frame 48 × 40 (16 pixels wider, all on the staff side) and the crouch frame 32 × 30. With the pivot at each frame's center, the body slides 8 pixels to the left during the cast and the crouch hangs 5 pixels above the ground. With the pivot on the feet in every frame, nothing moves except the pose.

There are two fixes. Give each frame its own pivot at the feet, which Unity's Sprite Editor allows, as do atlas files with a pivot per frame. Or, simpler and supported everywhere: draw or export every frame of a character on the same canvas, with the feet at the same spot, ideally the bottom center. Then one pivot is right for all of them.

Why sprites jump when they flip

Turning a character around is usually a mirror image instead of new art. A mirror needs an axis, and engines don't agree on where it is.

In the cast frame the feet are 16 pixels from the left edge, not in the middle. Mirrored around the frame's center they move to 32 pixels, so the character jumps 16 pixels each time it turns. Mirrored around the feet, it doesn't move.

• Unity mirrors around the pivot. The pivot is the origin of the sprite's own coordinates, and the Sprite Renderer's Flip mirrors those coordinates; per the documentation, it doesn't move the GameObject.
• Godot 4's flip_h mirrors the texture inside its own drawing rectangle, wherever centered and offset put that rectangle. In the Sprite2D source, flipping negates the rectangle's width but leaves the offset alone.
• Phaser's documentation for flipX says "Flipping always takes place from the middle of the texture". The origin you set doesn't change that. The exception is a frame that got its pivot from an atlas file, which flips around that pivot.

The rule that makes all three behave: keep the feet in the horizontal middle of every frame. Then the frame's center and the feet share one axis, and a flip never moves the character.

Setting the pivot in each engine

Unity

For a sheet sliced into several sprites, open the Sprite Editor, select a sprite and set Pivot: one of nine presets, or Custom. With Custom, Pivot Unit Mode chooses between Normalized and Pixels, and Custom Pivot takes the values. The Sprite Editor reference confirms that both modes start at 0, 0 in the bottom-left corner, so the feet of a 64 × 40 frame are 0.5, 0 normalized or 32, 0 in pixels. A single-sprite texture has the same Pivot setting in its import settings.

The pivot is in sprite pixels; Pixels Per Unit turns pixels into world units. With Pixels Per Unit at 32, a 64 × 40 frame is 2 units wide and 1.25 units tall, and with the pivot at the feet it extends 1 unit to each side of the GameObject's position and 1.25 units up. If a character's frames come from several textures, give them all the same Pixels Per Unit, or frames will change size as they play.

Godot 4

Sprite2D and AnimatedSprite2D don't have a pivot property; they have Centered and Offset. With Centered on (the default), the texture's middle sits on the node's position, and Offset moves the texture from there, with positive y pointing down. To put the feet of 64 × 40 frames on the node's position, keep Centered on and set Offset to (0, -20), half the frame height upward. With Centered off, the same point needs (-32, -40).

Because flip_h doesn't mirror the offset, keep the feet horizontally centered in the frame. If you can't, mirror a parent node with a negative x scale instead, which mirrors around that node's origin. The Node2D documentation warns that a negative x scale reads back as a negative y scale plus a 180° rotation, so don't be surprised by the numbers.

Phaser

Phaser calls the pivot the origin. It runs from 0 to 1 and defaults to 0.5, the center:

// a grid sheet of 64 × 40 frames with the feet at the bottom center of each
this.load.spritesheet('wanderer', 'wanderer-poses-64x40.png', { frameWidth: 64, frameHeight: 40 })

// in create(): (160, 120) is now the point between the character's feet
const hero = this.add.sprite(160, 120, 'wanderer', 0).setOrigin(0.5, 1)
hero.setFlipX(true) // mirrors inside the frame; the feet are in its middle, so they stay put

When a frame comes from an atlas whose JSON has a pivot (or anchor) for it, Phaser applies it as the origin every time that frame is shown.

Plain canvas

Drawing sprites yourself, translate to the position first and draw the frame offset by its pivot; a flip is then a scale around the pivot. This runs as written:

// Draw a frame so its pivot lands on (x, y). pivotX and pivotY run from 0 to 1,
// from the top-left. A flip mirrors around the pivot, so the feet stay put.
function drawWithPivot(ctx, sheet, r, x, y, pivotX, pivotY, flipX = false) {
  ctx.save()
  ctx.translate(x, y)
  if (flipX) ctx.scale(-1, 1)
  ctx.drawImage(sheet, r.x, r.y, r.w, r.h, -pivotX * r.w, -pivotY * r.h, r.w, r.h)
  ctx.restore()
}

SpritePilot's pivot setting

In Export & Download, Pivot Point offers the same nine presets as a 3 × 3 grid, with x and y at 0, 0.5 or 1; the default is the center. It appears when the metadata format is TexturePacker, Phaser 3 or Godot JSON, and SpritePilot writes it into every frame, for example "pivot": { "x": 0.5, "y": 1 } for the bottom center. SpriteFrames (.tres), Aseprite JSON, Basic JSON and CSS don't carry a pivot.

What happens next depends on the reader. Phaser applies the pivot automatically, as described above. PixiJS reads a field called anchor rather than pivot, so set the anchor in code. Godot JSON is for your own import script, and in Unity you set the pivot in the Sprite Editor.

One pivot applies to the whole export, which is another reason to put every frame on the same canvas with the feet at the bottom center. The character in this article is drawn that way and free to use (CC0): download the three poses, 64 × 40 pixels each.

A checklist

1. Things that spin get a center pivot; things that stand get a feet pivot.
2. Draw all frames of a character on one canvas size, feet at the same pixel in each.
3. Keep the feet in the horizontal middle of the frame so flips don't move the character.
4. Check the convention: Unity counts y from the bottom, Phaser and SpritePilot from the top.
5. Play the animation and flip it once before building a level around it.

For the related problem of frames that lost their position when their empty border was cut off, see Trimming Transparent Pixels From Sprites.

The hard limit: maximum texture size

Every GPU has a largest texture it will accept, measured as the maximum width or height in pixels. WebGL reports it as MAX_TEXTURE_SIZE. Go one pixel over and the texture simply isn't created. In a Chromium test, uploading a texture one pixel wider than the limit failed with an INVALID_VALUE error, and the sprite drawn with it came out solid black.

How big is the limit on players' devices? web3dsurvey.com collects WebGL capabilities from visitors' browsers. Its WebGL 2 figures, checked in October 2026:

So:

• 4096 × 4096 works everywhere. MDN's WebGL best practices lists 4096 among the limits you can count on, and Godot's import documentation warns that mobile and web platforms usually can't display textures larger than 4096 × 4096.
• 8192 is safe on Windows, Mac and iOS, but about one Android device in four can't load it.
• 16384 rules out Android. Only 3% of Android reports reach it, against 94–98% on iOS, Windows and macOS.

Native engines have their own ceilings. Unity's texture importer goes up to 16384, and its manual lists the maximum per class of GPU: 4096 for OpenGL ES 3.0 devices, 8192 for OpenGL ES 3.1 and 16384 for desktop GPUs from the DirectX 11 era on. Unity also scales any texture larger than the importer's Max Size setting down at import time, so a 4096 sheet imported with Max Size 2048 loses half its resolution, and pixel art comes out blurred. Godot's Size Limit import option does the same on purpose, which is one way to make a sheet fit a phone.

To see the limit of the device in front of you, paste this into the browser's console:

const canvas = document.createElement('canvas')
const gl = canvas.getContext('webgl2') || canvas.getContext('webgl')
console.log(gl.getParameter(gl.MAX_TEXTURE_SIZE))

Memory: width × height × 4 bytes, plus a third for mipmaps

A sheet that fits the limit can still be too heavy. Once loaded, an uncompressed texture costs 4 bytes per pixel (red, green, blue and alpha), whatever file format it came from; PNG, WebP or JPG for Game Sprites? shows why. Memory grows with the square of the side, so doubling the width and height of a sheet multiplies its memory by four:

The arithmetic for 2048: 2048 × 2048 × 4 = 16,777,216 bytes, which is 16 MiB.

Mipmaps are pre-shrunk copies of the texture at half, a quarter, an eighth of the size, and so on, used when the texture is drawn small. Each level has a quarter of the pixels of the one before, so the whole chain adds 1/4 + 1/16 + 1/64 + … = 1/3 to the memory. Godot's documentation lists the same 21.33 MiB for a 2048 × 2048 RGBA texture with mipmaps. Most 2D games don't need them: Godot's default import settings for 2D leave them off, and they soften pixel art.

GPU compression formats such as DXT (also called BC), ETC2 and ASTC store 8 bits per pixel or fewer instead of 32, according to Unity's table of formats: a quarter of the memory at most. They are lossy and work in small blocks of pixels, though, and Godot's documentation recommends keeping VRAM compression off for pixel art. One more multiplier to watch: Unity's Read/Write import option keeps an extra copy for scripts, which the manual says doubles the memory the texture needs.

When to split one sheet into several

Sheets exist to save work for the GPU. Unity's manual puts it plainly: it only needs one draw call for all the sprites in a sprite atlas. Every time the game draws from a different texture, it has to switch. So split along the lines of what is drawn together:

• Split when a sheet passes your platform's limit. For web and mobile, that means 4096.
• Split by when things are needed. A level's tiles and enemies don't need to sit in memory while another level plays.
• Keep each animation on one texture, and keep sprites that appear on screen together on the same one.

Big frames fill sheets quickly. A 1920 × 1080 video frame fits 4 across and 7 down on an 8192 × 8192 sheet, so that sheet holds 28 frames. A 4096 sheet holds 6.

Power of two: when it still matters

Power-of-two sizes are 256, 512, 1024, 2048, 4096 and so on. Older graphics hardware required them. Today it depends on where the sheet runs:

• WebGL 1 can't use mipmaps or repeating (tiling) wrap modes on textures whose sides aren't powers of two; MDN says they must use CLAMP_TO_EDGE. In the Chromium test, a 96 × 64 texture set to repeat drew solid black and generateMipmap failed, while 128 × 64 worked. A sprite sheet drawn the usual way, clamped and without mipmaps, works at any size.
• WebGL 2 lifts the restriction: Khronos listed non-power-of-two textures among WebGL 2.0's additions, and the same 96 × 64 texture repeated and mipmapped without errors.
• Unity accepts other sizes, but its manual notes that they "generally take slightly more memory and might be slower for the GPU to sample". On a platform without support, Unity scales and pads the texture up to the next power of two, and the Non Power of 2 import option does that on purpose. PVRTC compression on iOS also needs square textures: Unity's own example turns a 257 × 511 texture into 512 × 512.
• Godot recommends power-of-two sizes but doesn't require them, and textures don't have to be square.

Where you do need a power of two, don't pad blindly. The figure above shows a 1536 × 1280 sheet padded to 2048 × 2048: 16 MiB, more than half of it empty. The same 120 frames re-packed 16 across fill 2048 × 1024 almost exactly, for 8 MiB.

What SpritePilot does with sheet sizes

SpritePilot's Sheet Maker packs separate images into one sheet. Its Max Width and Max Height go from 256 to 8192 pixels, starting at 2048, and the sheet comes out as the tight box around the packed images. It doesn't pad to a power of two. When the images don't fit, it tells you the size that would hold them all, or, if even 8192 × 8192 is too small, that they need to be split over several sheets.

The GIF to Sprite Sheet and Video to Sprite Sheet converters also stop at 8192 pixels a side. Over that, the download is disabled and a warning says which column counts would fit. For video, the Auto frame size picks the largest frames that still fit one 8192 sheet. Treat 8192 as SpritePilot's ceiling, not a target: for Android and the web, set Max Width and Max Height to 4096 or less. To fit more frames into the same sheet, see trimming transparent pixels.

A sizing checklist

• Web and mobile: keep each sheet at 4096 × 4096 or less. Windows and Mac only: 8192 is safe.
• Memory = width × height × 4 bytes. Mipmaps add a third; most 2D games can leave them off.
• Split by use: one animation per texture, things on screen together on one sheet, levels loaded separately.
• Powers of two matter for WebGL 1 with mipmaps or tiling, for PVRTC, and on platforms without support. Re-pack to fill one rather than padding.
• Check a device's real limit with gl.getParameter(gl.MAX_TEXTURE_SIZE).

That difference decides how you load the file, how much memory it takes, and what it can hold. Here are both, with real measurements from the same set of sprites.

A sprite sheet is a grid you can describe in one line

In a grid sheet every cell is the same size. Give your engine the frame width and height (plus the margin and spacing, if the sheet has gaps) and it can work out every frame's rectangle with arithmetic. Frames are referred to by number: frame 0, frame 1, and so on, left to right and top to bottom.

Phaser's loader documentation draws the line clearly: in Phaser, a sprite sheet means a fixed-size sheet whose frames are referenced by number, while in a texture atlas frames are packed to take up the least space and are referenced by name. It also warns that some software uses "sprite sheet" to mean an atlas.

Unity, Godot and Phaser all cut a grid by themselves:

• Unity: Sprite Editor → Slice → Grid By Cell Size or Grid By Cell Count, with Offset and Padding for sheets with gaps.
• Godot 4: a Sprite2D's Hframes and Vframes, or Add frames from a Sprite Sheet in the SpriteFrames panel.
• Phaser: this.load.spritesheet() with frameWidth and frameHeight.

The catch is that every cell is as big as the biggest sprite. That's fine for an animation whose frames all share one canvas, and wasteful for anything else. If you have a grid sheet and no notes, How to Find the Frame Size of a Sprite Sheet shows how to recover the numbers.

A texture atlas is packed and comes with a map

An atlas places sprites of any size wherever they fit. Because no formula can find them again, the packer writes a data file next to the image: usually JSON, sometimes XML or a .plist. Each entry names a sprite and gives its rectangle.

This is a real entry, plus the file's meta section, from a sheet packed by SpritePilot's Sheet Maker in the TexturePacker "JSON (Hash)" layout, which Phaser and PixiJS read directly:

"chest.png": {
  "frame": { "x": 130, "y": 102, "w": 28, "h": 22 },
  "rotated": false,
  "trimmed": false,
  "spriteSourceSize": { "x": 0, "y": 0, "w": 28, "h": 22 },
  "sourceSize": { "w": 28, "h": 22 }
},
…
"meta": {
  "app": "SpritePilot",
  "version": "1.0",
  "image": "sprite-sheet.png",
  "format": "RGBA8888",
  "size": { "w": 164, "h": 162 },
  "scale": "1"
}

What each field means:

• frame — where the sprite's pixels are in the sheet.
• rotated — whether the packer turned the sprite 90° to make it fit. Some packers do; SpritePilot never does.
• trimmed, spriteSourceSize, sourceSize — whether the transparent border around the sprite was cut off, and where the remaining pixels sat in the original image, so the engine can put them back in the same place. Trimming Transparent Pixels From Sprites covers this in detail.
• meta — the image file the rectangles refer to and its size.

The same 30 sprites, packed both ways

Here is one set of 30 original sprites packed twice by SpritePilot's Sheet Maker: a character in three poses, eleven props from 14 × 12 to 40 × 56 pixels, eight 32 × 32 coin frames and eight 16 × 16 tiles. Same images, same 2 px padding; only the Algorithm setting changed.

The sprites themselves cover 21,020 pixels. The grid makes every cell 56 × 56, the widest sprite by the tallest, so a 16 × 16 tile uses 8% of its cell. The packer puts each sprite against its neighbors; most of what's left is the padding. Packed again with 0 padding, the atlas comes out at 152 × 150 pixels and only 7.8% empty.

Notice the last two rows. The PNG files differ by less than 3 KB, because PNG compresses big transparent areas to almost nothing. Memory is different: unless the engine converts it to a compressed GPU format, a loaded texture costs 4 bytes per pixel. Unity's texture format reference lists RGBA 32 bit at 32 bits per pixel, 4 MB for a 1024 × 1024 texture, and Godot's import documentation describes lossless textures as small on disk but large in memory. Judge a sheet by its pixel count, not its file size: here the grid costs 3.75 times as much memory.

Atlases and draw calls

The other reason atlases exist is speed. Unity's manual on sprite atlases explains that when each sprite has its own texture, Unity sends a separate draw call to the GPU for each one, while sprites in one atlas need only one draw call.

How that plays out depends on the engine:

• Unity packs atlases for you. Import sprites or grid sheets as usual, add them to a Sprite Atlas asset, and Unity combines them. Its packing options include Tight Packing (packing each sprite by its mesh shape instead of its rectangle), Allow Rotation and Padding, 4 pixels by default.
• Godot 4 has a TextureAtlas import type; the importing images documentation says it "can be used to reduce memory usage for animated 2D sprites".
• Phaser loads a packed atlas with this.load.atlas(), which accepts the JSON Hash and JSON Array formats that TexturePacker and SpritePilot write, and PixiJS reads the same fields. In web engines like these you usually ship a ready-made atlas file.

What changes in code

Under the hood, the only difference is where the rectangle comes from. This plain JavaScript draws from either kind of sheet onto a canvas, and was checked pixel for pixel against SpritePilot's real output:

// A grid: the rectangle comes from arithmetic.
function gridFrame(index, { frameWidth, frameHeight, columns, margin = 0, spacing = 0 }) {
  const col = index % columns
  const row = Math.floor(index / columns)
  return {
    x: margin + col * (frameWidth + spacing),
    y: margin + row * (frameHeight + spacing),
    w: frameWidth,
    h: frameHeight,
  }
}

// An atlas: the rectangle comes from the data file, by name.
function atlasFrame(atlas, name) {
  return atlas.frames[name].frame
}

// Drawing is the same call either way.
function drawRect(ctx, sheet, r, x, y) {
  ctx.drawImage(sheet, r.x, r.y, r.w, r.h, x, y, r.w, r.h)
}

A grid needs a few numbers for the whole sheet; an atlas needs one entry per sprite, and that list has to travel with the image.

Which one to use

Use a grid sheet when:

• the sprites are frames of one animation drawn on the same canvas size,
• the image is a tileset: tile map editors and engines expect tiles on a regular grid,
• you want the simplest import: every engine slices a grid without extra files.

Use a packed atlas when:

• the sprites have different sizes: items, props, UI icons, effects,
• you have many animations and want them in one texture,
• frames have lots of empty space that trimming could remove,
• memory or draw calls matter, as they do on phones and in browsers.

You can also mix them: an atlas can hold animation frames named walk_0, walk_1 and so on, next to everything else.

Try it

Load your images into SpritePilot's Sheet Maker, generate the sheet once, then switch Algorithm between Bin Packing and Simple Grid and compare the dimensions it reports. It downloads the PNG with a TexturePacker JSON (Hash) file or a simple list, runs in your browser and uploads nothing. The step-by-step is in How to Make a Sprite Sheet, and Sprite Sheet Export Formats Explained covers which data format suits which engine.

This article takes a real 8-frame bouncing ball apart, measures it, and shows the three things that make squash and stretch work: where it goes, how much, and for how long.

What squash and stretch tells the viewer

• Squash is a shape compressing against something: a ball hitting the floor, a character landing, a fist meeting a wall. It shows force. How much the shape gives tells the viewer what it's made of: a rubber ball flattens a lot, a bowling ball hardly at all.
• Stretch is a shape lengthening along its direction of travel. It shows speed, and in a sprite it also bridges the gap between two positions that are far apart, so a fast drop reads as one motion instead of a jump.

Both only work if the object still looks like the same object. That comes down to keeping its size, which you can measure.

The bouncing ball, frame by frame

SpritePilot's bundled sample, ball-bounce.png, is a 256 × 128 sheet with 8 frames of 64 × 64 pixels, 4 columns by 2 rows. Here is every frame, with the ball's size and the number of pixels it covers:

Three things are going on:

1. Spacing. The ball's top edge moves 3, then 5, then 9 pixels between frames 1 and 4. The gaps grow because the ball is accelerating under gravity, and the frames after the impact repeat them in reverse.
2. Stretch. Without the one-pixel bumps at its edges, frame 1's ball is 23 × 25 pixels. The falling frames are 23 × 26: one pixel taller, a light stretch along the direction of travel.
3. Squash. Frame 5 is 37 × 17 pixels, 14 pixels wider and 9 pixels shorter than the falling frames. Its bottom edge sits on the lowest row the ball reaches, its highlight flattens with it, and its shadow widens from 17 to 33 pixels.

The squash lasts exactly one frame. Frame 6 is already the stretched rising shape again.

Keep the area the same

The rule that keeps a squashed ball looking like the same ball is to keep its volume. On a flat sprite, volume means area, and the area of an ellipse is π ÷ 4 × width × height. The π ÷ 4 never changes, so the rule becomes simple arithmetic: keep width × height the same.

For a 24 × 24 ball, width × height is 576:

• Squash it to 16 pixels tall and it needs 576 ÷ 16 = 36 pixels of width.
• Stretch it to 20 pixels wide and it needs 576 ÷ 20 = 28.8, so 29 pixels of height.
• Flatten it to 16 without widening and it keeps only 24 × 16 = 384, two thirds of its area. It reads as the ball shrinking, not squashing.

Pixel art can't hit these numbers exactly, and it doesn't need to. The sample's squash frame covers 445 pixels against 487 for the round frame, 91% of the area, and it reads as the same ball. Aim for within about 10%, and count pixels when a frame looks off: a squash that "looks wrong" is often just too small.

Timing: squash on impact, stretch when it's fast

Here is the sample next to two edited copies. The only difference is frame 5:

With no squash, the ball touches the ground and leaves as if it hit something rigid. With the sample's squash, the impact has weight. The squash without widening looks like the ball shrinks for a moment, which reads as an error.

Some timing guidelines that follow from this:

• Squash on the contact frame. That's the frame where the force is. At 10 to 12 fps, one frame lasts about 83 to 100 ms, which is enough for the eye to register it.
• Hold the squash longer for a softer object. Two frames of squash suggest something that takes time to recover its shape, such as a slime or a sack.
• Stretch on the fastest frames, just before and just after the impact, where the gaps between positions are largest. Don't stretch at the top of the bounce, where the ball is barely moving.
• Match the amount to the material. The sample squashes to about two thirds of its height. A bowling ball might lose a pixel or two; a water balloon could lose half.

If you want different frames to stay on screen for different times, for example a two-frame hold on the squash, How Fast Should Pixel Art Animate? shows how to set per-frame durations in Godot, Phaser, Unity and Aseprite.

Squash and stretch at pixel-art sizes

Small sprites have fewer pixels to give, so every pixel of squash counts:

• One pixel is a lot. On a 16 × 16 ball, losing one pixel of height is a 6% squash and already visible. Squashing it from 16 to 12 pixels tall needs 256 ÷ 12 ≈ 21 pixels of width.
• Squash from the contact point. The edge that touches the ground stays on the same row of pixels and the shape grows outward from there. In the sample, the squash frame's bottom edge is the lowest row of the whole bounce.
• Squash the details too. The sample's highlight goes from 9 × 9 to 11 × 5 pixels. A highlight left round on a flat ball breaks the illusion.
• For characters, think in body parts. On landing, drop the head and body a pixel or two and spread the feet or widen the torso by the same amount. On take-off, squash into a crouch first, then stretch upward as the feet leave the ground.

Two engine details matter once the frames have different shapes:

• Keep the pivot at the bottom. If your frames are trimmed to their content, the squash frame's rectangle is shorter than the others. With a centered pivot it would pop up into the air; with a bottom-center pivot it stays on the ground. Sprite pivot points covers how to set one.
• Draw it rather than scaling in code. Many games fake squash by scaling the sprite, for example to 120% wide and 80% tall. That works for smooth art, but on pixel art a non-integer scale makes some pixels wider than others (more on scaling pixel art). Drawn frames keep the pixel grid intact.

Try it

The ball from this article is SpritePilot's sample sheet. Open the Sprite Player, click Try a sample (it sets 4 columns and 2 rows for you), then press the right arrow key four times to step to frame 5:

Play it at 8, 10 and 12 fps and watch how long the squash stays visible. To try your own version, download the sample sheet, edit frame 5 in any pixel editor and load it back into the player. The player runs in your browser and nothing is uploaded.

In short

• Squash shows force and material; stretch shows speed and bridges big gaps between frames.
• Keep width × height roughly constant, within about 10% of the round shape.
• Squash on the contact frame, for one frame unless the object is soft; stretch on the fastest frames.
• At pixel-art sizes, squash from the contact point, squash the details too, and keep the pivot at the bottom.

This article measures what trimming saves, shows the numbers an atlas stores to undo it, and lists which loaders use them.

How much trimming saves

Take SpritePilot's bouncing-ball sample: eight frames of 64 × 64 pixels, a ball falling, squashing on the ground and rising again, with its shadow on the floor in every frame.

Two details explain the gap between the rows. First, trimming only cuts the outer border: the ball frames keep the empty column of air between the ball and its shadow, so the tallest one is still 60 pixels high. Second, SpritePilot's Export & Download lays trimmed frames out in a grid whose cells fit the largest trimmed frame (37 × 60 here), so the sheet saves less than the frames do. A packer that places each trimmed frame individually gets closer to the frame total; SpritePilot's Export keeps the simpler grid. Sprite Sheet vs. Texture Atlas measures that difference for untrimmed sprites.

The savings depend entirely on the art. Small objects on big canvases gain the most; frames that fill their canvas, like video frames or full-screen backgrounds, gain nothing.

The three numbers an atlas keeps

A trimmed frame can't be drawn correctly on its own, so the atlas stores the information needed to put it back. This is a real entry from SpritePilot's TexturePacker JSON with Trim transparency on, for the first ball frame:

"sprite_0001.png": {
  "frame": { "x": 6, "y": 0, "w": 25, "h": 60 },
  "rotated": false,
  "trimmed": true,
  "spriteSourceSize": { "x": 20, "y": 3, "w": 25, "h": 60 },
  "sourceSize": { "w": 64, "h": 64 },
  "pivot": { "x": 0.5, "y": 0.5 }
}

• sourceSize is the original canvas: 64 × 64.
• spriteSourceSize is where the kept pixels sat on that canvas: 20 pixels from the left, 3 from the top, 25 × 60 in size.
• frame is where those pixels are now in the sheet.
• trimmed: true tells the loader the first two differ.

SpritePilot writes the same information into its other formats: Phaser 3 and Aseprite JSON use the same fields, Godot JSON and Basic JSON store an offset and a sourceSize, the Godot 4 SpriteFrames (.tres) file gives each trimmed frame an AtlasTexture margin, and CSS sprites get padding that restores the original box. Trimming keeps any pixel with even the faintest opacity, so soft glows and shadows survive.

Why trimmed frames jitter

A trimmed frame is a different size in almost every pose. If the engine ignores the offsets and positions each frame by its own size, every frame lands somewhere slightly different.

On the left, each frame is centered by its trimmed size. The tallest frame is 60 pixels high and the squashed one only 28, so the shadow's bottom edge swings 16 pixels up and down and the squashed ball hangs in the air. The pixels are all correct; only their placement is wrong.

If you draw sprites yourself, the fix is one addition. This canvas code puts each trimmed frame back on its original canvas; drawing all eight frames this way rebuilds the original 64 × 64 frames pixel for pixel:

// Draw a frame from a TexturePacker-style atlas exactly where the
// untrimmed frame would have been. (x, y) is that frame's top-left corner.
function drawFrame(ctx, sheet, f, x, y) {
  ctx.drawImage(
    sheet,
    f.frame.x, f.frame.y, f.frame.w, f.frame.h,          // where the pixels are now
    x + f.spriteSourceSize.x, y + f.spriteSourceSize.y,  // where they were
    f.frame.w, f.frame.h,
  )
}

// To center a sprite on (cx, cy), use the original size, not the trimmed one.
function drawFrameCentered(ctx, sheet, f, cx, cy) {
  drawFrame(ctx, sheet, f, cx - f.sourceSize.w / 2, cy - f.sourceSize.h / 2)
}

Centering by f.frame.w and f.frame.h instead is exactly the mistake in the left half of the animation: it matched the original frames zero times out of eight.

Which engines use the offsets

• Phaser (this.load.atlas, JSON Hash or JSON Array): the atlas parser reads sourceSize and spriteSourceSize for every frame marked trimmed, and the frame keeps its untrimmed size for positioning. Trimmed atlases work without extra code.
• PixiJS: the Spritesheet parser uses sourceSize as the texture's original size and spriteSourceSize as its trim, unless the frame says trimmed: false.
• Godot 4: an AtlasTexture is drawn at its region size plus its margin size, with the region offset by the margin's position. That's how SpritePilot's SpriteFrames export restores trimmed frames: assign the .tres to an AnimatedSprite2D's Sprite Frames and every frame keeps its original 64 × 64 box.
• Unity works the other way round. You normally import untrimmed frames and let a Sprite Atlas pack them; its Tight Packing option packs each sprite by its mesh shape instead of its rectangle, so the empty space is dealt with inside Unity.

If your loader only reads frame, expect the left half of the GIF. In that case export without trimming, or position frames with the offsets yourself.

When not to trim

• Tiles. A tileset has to stay a regular grid with every tile the same size. Trimming a tile with transparent edges breaks the grid.
• Anything sliced as a grid. Phaser's load.spritesheet, a Godot Sprite2D's Hframes and Vframes, and Unity's Grid By Cell Size never see the offsets. SpritePilot's trimmed export still looks like a grid, because each frame is centered in a cell, but slicing it as one gives you the left half of the animation above.
• Frames that fill their canvas. Video frames and opaque backgrounds have no transparent border to cut. SpritePilot marks such frames trimmed: false and leaves them alone.
• Tiny sprites. Trimming a 16 × 16 icon saves at most 1 KB of memory and adds a rule every loader must follow.

Try it

Get frames into SpritePilot, for example by slicing a sheet with Grid Slice or sending them from the GIF or video converter, then open Export & Download. Tick Trim transparency, choose TexturePacker, Phaser 3, Godot JSON or SpriteFrames metadata, and download. The preview's heading adds "trimmed" so you can see it's on. Everything runs in your browser.

Before you ship, check one thing: play the trimmed animation in your engine next to the untrimmed one. If the shadow or the feet move, the loader isn't applying the offsets. For what each metadata format is for, see Sprite Sheet Export Formats Explained; for choosing the point a sprite is positioned by, see Sprite Pivot Points Explained.

A walk is two steps of four key poses

A walk cycle is one full repeat of the motion: a step with the right leg, then a step with the left. The second step is the first with the legs and arms swapped, so a cycle is two mirrored halves and its frame count is almost always even.

Each step passes through four key poses. The names below are the ones popularized by Richard Williams' The Animator's Survival Kit:

• Contact: the front heel touches down. The legs are spread their widest, and so are the arms, which swing opposite the legs.
• Down: the front foot takes the weight, its knee bends and the body drops to its lowest point.
• Passing: the supporting leg is straight under the body while the other leg passes it with the foot lifted.
• Up: the back foot pushes off its toes and the body rises to its highest point as the free leg swings forward.

That rise and fall of the hips is what gives a walk its weight. Keep an eye on it: it's the first thing you lose when you cut frames.

What 4, 6 and 8 frames keep

Frames in a cycle are evenly spaced in time, so the frame count decides exactly where each drawing lands within a step:

• 8 frames hold all four key poses, so the weight lands on the down and the push-off shows on the up.
• 6 frames put the two drawings after each contact at a third and two thirds of a step, between the classic poses. Draw them as a low pose and a high pose and most of the bounce survives: in the walk drawn for this article, the hips rise and fall by 3.6% of the figure's height, against 4.4% with 8 frames.
• 4 frames keep only contact and passing. The legs still alternate, but the hips move just 0.4% of the height, so the walk glides. A simple fix is to raise the body by a pixel on both passing frames, which puts back some bounce.

Here is the same walk at the same pace, 0.72 seconds per cycle, with each frame count:

Four frames read as walking but look stiff at this pace. Six come surprisingly close to eight. Playing a 4-frame walk faster doesn't make it smoother; it makes the character walk faster, which brings us to speed further down.

Small sprites and large sprites need different counts

The size of the sprite changes the answer, because pixel art can only move in whole pixels.

Take the planted foot. Over one step it moves back by one step length, and it should do so evenly, the same number of pixels every frame. That gives a simple test: step length ÷ drawings per step should be a whole number.

• 16 px tall: a step might be 6 px. With 4 frames the foot moves 3 px per frame, and with 6 frames it moves 2 px. With 8 frames it would move 1.5 px, which can't be drawn: it alternates between 1 and 2 px and the foot wobbles. Small sprites often look cleaner with 4 or 6 frames than with 8.
• 32 px tall: a 12 px step works with all three: 6, 4 or 3 px per frame. Six or eight frames suit this size well.
• 64 px and taller: the down and up poses are several pixels apart, and arms, hair and clothes have room to follow through. Eight frames is a sensible minimum, and large, smooth characters can use 12 or 16.

If your step doesn't divide evenly, change the step: a 14 px step won't split into 4 drawings per step, but 12 or 16 will.

Match the cycle to the movement speed

Feet slide when the character moves at a different speed from the one the walk was drawn for. In a walk cycle the body stays in place on the sprite sheet and the planted foot moves backward. In the game the body moves forward. When the two distances match, the planted foot stays fixed on the ground.

So the speed a walk is drawn for is:

speed = foot travel per frame × frame rate = 2 × step length × frame rate ÷ frames per cycle

For a 32 px character with a 12 px step, drawn with 8 frames and played at 10 fps:

• foot travel per frame: 12 px ÷ 4 drawings per step = 3 px
• speed: 3 px × 10 fps = 30 px per second, which is 0.5 px per tick in a game running at 60 ticks per second

If your game moves the character at a different speed, change one of three things:

1. The frame rate. At 48 px per second, the same walk needs 48 ÷ 3 = 16 fps. That works for small adjustments, but a walk played much faster than it was drawn starts to look frantic.
2. The step length. Redraw with a 16 px step and the foot travels 4 px per frame, so 12 fps gives 48 px per second.
3. The movement speed. Sometimes the honest fix is to move the character at the speed the animation suggests.

When the speed varies, for example with an analog stick, scale the playback rate by current speed ÷ drawn speed. Engines expose this directly: speed_scale on Godot 4's AnimatedSprite2D, Animator.speed in Unity and timeScale on a Phaser sprite's anims.

One last detail: if the character moves smoothly every tick but the drawing changes only 10 times a second, the planted foot creeps forward with the body while each drawing is on screen, then snaps back by the foot travel on the next one. In the example that's 3 px. More frames make the creep smaller. Some games instead move the character in steps that line up with the frame changes, which keeps the feet perfectly planted at the cost of slightly jerkier movement.

Try it

Draw a walk in SpritePilot's Pixel Art Editor: start with the two contact poses, then add the passing poses between them (a working 4-frame walk), then the downs and ups if the sprite is big enough. Duplicate frame copies a pose so you only move the limbs. Onion skin shows the previous frame underneath, which makes even foot travel easy to check (how onion skinning works). The Preview plays the frames at 1 to 30 FPS, and Download Sheet PNG saves them as a strip you can check in the Sprite Player. New to the editor? How to Draw Your Own Pixel Art Sprite covers the tools. For picking the playback rate, see How Fast Should Pixel Art Animate?

In short

• A walk cycle is two mirrored steps; each step has four key poses: contact, down, passing, up.
• 8 frames keep all four poses, 6 frames keep most of the bounce, 4 frames keep contact and passing only.
• Small sprites: choose a frame count that divides the step length into whole pixels.
• Drawn speed = foot travel per frame × frame rate. Match it, or scale the playback rate with the speed.

This article builds the program once and then explains each of those parts. All the code was run in Chromium, and the frames it drew were checked pixel by pixel.

The whole program

The sheet is the bouncing-ball sample, ball-bounce.png: 8 frames of 64 × 64 pixels in 4 columns and 2 rows. Put it next to an HTML file with this in it:

<canvas id="game"></canvas>
<script type="module">
  const canvas = document.getElementById('game')
  const ctx = canvas.getContext('2d')

  const FRAME_W = 64       // one frame, in sheet pixels
  const FRAME_H = 64
  const COLUMNS = 4        // frames per row in the sheet
  const FRAME_COUNT = 8
  const FRAME_MS = 100     // 10 frames per second
  const SCALE = 3          // each sheet pixel becomes 3 × 3 CSS pixels

  const sheet = new Image()
  sheet.src = 'ball-bounce.png'
  await sheet.decode()

  // A whole number of screen pixels per sheet pixel, on any screen
  const zoom = Math.max(1, Math.round(SCALE * window.devicePixelRatio))
  canvas.width = FRAME_W * zoom
  canvas.height = FRAME_H * zoom
  canvas.style.width = canvas.width / window.devicePixelRatio + 'px'
  canvas.style.height = canvas.height / window.devicePixelRatio + 'px'
  ctx.imageSmoothingEnabled = false   // after sizing: resizing the canvas resets it

  let start = null
  function tick(now) {
    if (start === null) start = now
    const frame = Math.floor((now - start) / FRAME_MS) % FRAME_COUNT
    const sx = (frame % COLUMNS) * FRAME_W
    const sy = Math.floor(frame / COLUMNS) * FRAME_H

    ctx.clearRect(0, 0, canvas.width, canvas.height)
    ctx.drawImage(sheet, sx, sy, FRAME_W, FRAME_H, 0, 0, FRAME_W * zoom, FRAME_H * zoom)
    requestAnimationFrame(tick)
  }
  requestAnimationFrame(tick)
</script>

type="module" is what allows await at the top level, so the loop only starts once the image is ready to draw. The sections below go through the program from the loop outwards.

Let time pick the frame, not the frame counter

requestAnimationFrame calls tick once before each repaint of the screen. How often that happens depends on the display: MDN notes that 60 Hz is the most common rate, but 75, 120 and 144 Hz are also widely used. So the number of calls tells you nothing about how much time has passed.

What does tell you is the timestamp the browser passes in, now, in milliseconds. The program measures the time since the first call and divides it by the frame duration:

• after 0–99 ms: floor(elapsed / 100) % 8 = frame 0,
• after 100–199 ms: frame 1,
• … after 800 ms it wraps back to frame 0.

The common mistake is advancing a counter on every call (frame++, perhaps every sixth call). That ties the speed to the monitor: on a 144 Hz screen it plays 144 ÷ 60 = 2.4 times as fast as on a 60 Hz one. With the timestamp, the speed is the same everywhere. In the test, the program was driven at 30, 60 and 144 calls per second, and at every moment all three showed the same frame.

Two more details come free. Most browsers pause requestAnimationFrame in background tabs; when the tab comes back, the elapsed time has jumped and the animation simply carries on in step. And if you later want per-frame timing, the frame can come from a list of durations instead of one FRAME_MS.

Choosing the frame and drawing it with drawImage

The frame number becomes a position in the sheet. With 4 columns, frame 7 (the last of the eight, counting from 0) is in column 7 % 4 = 3 and row floor(7 ÷ 4) = 1, so its top-left corner is at x = 3 × 64 = 192, y = 1 × 64 = 64.

The 9-argument form of drawImage copies a rectangle of one image onto the canvas, scaling it on the way. The source rectangle comes first, then the destination:

ctx.drawImage(image, sx, sy, sWidth, sHeight, dx, dy, dWidth, dHeight)

When the destination is bigger than the source, the frame is scaled up. That is how the program draws a 64-pixel frame 192 pixels wide (64 × 3) on a normal screen. Swap the two groups, for example by passing the destination first, and you get the wrong part of the sheet, in the wrong place, at the wrong size.

Keep pixel art crisp: imageSmoothingEnabled

By default the canvas smooths images it scales, blending neighboring pixels. That is right for photos and wrong for pixel art. imageSmoothingEnabled is true by default. Set it to false and scaled pixels stay hard-edged squares:

One trap: setting canvas.width or canvas.height resets the whole drawing context, smoothing included. In Chromium, ctx.imageSmoothingEnabled reads true again straight after a resize. That's why the program turns smoothing off after sizing the canvas. If your game resizes the canvas when the window changes size, set it again every time.

Sharp on high-DPI screens: devicePixelRatio

A canvas has two sizes: the bitmap it draws into (canvas.width and canvas.height) and the size it takes on the page (its CSS width and height). On a phone or a high-resolution laptop screen, one CSS pixel often covers 2 or 3 screen pixels. window.devicePixelRatio says how many. If the bitmap is only as big as the CSS size, the browser stretches it to fill the screen pixels, and the stretch is smooth: your carefully crisp pixels get soft edges.

So the program makes the bitmap big enough for the screen and shrinks the element back with CSS. It also rounds: zoom is the number of screen pixels per sheet pixel, and it has to be a whole number, or some art pixels come out one screen pixel wider than others. On a 2× screen, zoom is 3 × 2 = 6, so the canvas is 384 × 384 bitmap pixels shown at 192 × 192 CSS pixels. On a 1.5× screen, 3 × 1.5 = 4.5 rounds to 5: the bitmap is 320 pixels and the sprite comes out about 213 CSS pixels wide, a little over 3×, with every art pixel exactly 5 × 5 screen pixels. In Chromium screenshots at ratios 1, 1.25, 1.5, 2 and 3, the screen pixels matched the canvas bitmap exactly: square art pixels, nothing resampled.

The ratio can change while the page is open, when a window moves to another monitor or the visitor zooms. MDN's devicePixelRatio page shows how to listen for that with matchMedia; when it fires, run the sizing code again.

Reading frames from a JSON atlas

Grid math only works for a grid. A packed or trimmed sheet needs its data file, which lists every frame's rectangle. SpritePilot's Export & Download can write it in TexturePacker's "JSON hash" layout. This is one entry from an export of the ball with Trim transparency on:

"sprite_0001.png": {
  "frame": { "x": 6, "y": 0, "w": 25, "h": 60 },
  "rotated": false,
  "trimmed": true,
  "spriteSourceSize": { "x": 20, "y": 3, "w": 25, "h": 60 },
  "sourceSize": { "w": 64, "h": 64 },
  "pivot": { "x": 0.5, "y": 0.5 }
}

• frame is where the pixels are in the sheet: the source rectangle for drawImage.
• sourceSize is the frame's original size, 64 × 64, before the empty border was trimmed off.
• spriteSourceSize says where the trimmed pixels sat inside that original frame: 20 pixels from the left and 3 from the top. Draw them there and the ball stays put instead of jumping around.

The program becomes:

<canvas id="game"></canvas>
<script type="module">
  const canvas = document.getElementById('game')
  const ctx = canvas.getContext('2d')
  const FRAME_MS = 100
  const SCALE = 3

  async function loadImage(src) {
    const image = new Image()
    image.src = src
    await image.decode()
    return image
  }

  const [sheet, atlas] = await Promise.all([
    loadImage('sprite-sheet.png'),
    fetch('sprite-sheet.json').then(response => response.json()),
  ])
  const frames = Object.values(atlas.frames)   // in the order they were exported
  const { w, h } = frames[0].sourceSize        // the untrimmed frame size

  const zoom = Math.max(1, Math.round(SCALE * window.devicePixelRatio))
  canvas.width = w * zoom
  canvas.height = h * zoom
  canvas.style.width = canvas.width / window.devicePixelRatio + 'px'
  canvas.style.height = canvas.height / window.devicePixelRatio + 'px'
  ctx.imageSmoothingEnabled = false

  function drawFrame(f, x, y) {
    ctx.drawImage(
      sheet,
      f.frame.x, f.frame.y, f.frame.w, f.frame.h,   // where the pixels are in the sheet
      x + f.spriteSourceSize.x * zoom,              // trimmed frames: put the pixels back
      y + f.spriteSourceSize.y * zoom,              // where they sat in the full frame
      f.frame.w * zoom,
      f.frame.h * zoom,
    )
  }

  let start = null
  function tick(now) {
    if (start === null) start = now
    const index = Math.floor((now - start) / FRAME_MS) % frames.length
    ctx.clearRect(0, 0, canvas.width, canvas.height)
    drawFrame(frames[index], 0, 0)
    requestAnimationFrame(tick)
  }
  requestAnimationFrame(tick)
</script>

It was tested with three SpritePilot exports of the same 8 frames: trimmed (111 × 180 pixels), untrimmed (a 192 × 192 grid with an empty last cell) and from the Sheet Maker (262 × 130, with 2-pixel gaps). All three drew exactly the same pixels as the original sheet.

A few things to know:

• fetch doesn't work on a page opened straight from disk (file://). Serve the folder from any local web server.
• Object.values keeps the order the frames appear in the file, which is the export order. Frame names that are plain numbers ("1", "2") are the exception: JavaScript puts those in numeric order.
• If you add Animation Tags in SpritePilot (walk, idle…), the export lists them in atlas.meta.frameTags with a from and to frame index. frames.slice(tag.from, tag.to + 1) is that animation's frame list.
• SpritePilot never rotates frames. Some packers do, and mark it with "rotated": true; this code doesn't handle rotated frames.

To make an atlas from separate frame images, the Sheet Maker packs them in your browser and writes this same JSON, with the frames in the order you added them. To re-export frames that are already in SpritePilot, with trimming, pivots or animation tags, use Export & Download; Sprite Sheet Export Formats Explained compares its other formats. To check a sheet's frame size and speed before writing any code, play it in the Sprite Player.

In short

• Pick the frame from elapsed time: Math.floor((now - start) / FRAME_MS) % frameCount. Never count calls.
• drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh): source rectangle first, destination second.
• ctx.imageSmoothingEnabled = false for pixel art, set again after every canvas resize.
• Bitmap size = CSS size × devicePixelRatio, with a whole number of screen pixels per art pixel.
• From an atlas: draw frame at spriteSourceSize inside a box of sourceSize.
• For the same animation without JavaScript, see Animate a Sprite Sheet With CSS steps().

Every snippet below was run in Chromium and checked frame by frame.

The recipe for a one-row strip

The example is an 8-frame coin, 32 × 32 pixels per frame, in a strip 256 pixels wide (coin-spin-strip.png, free to use). The element is exactly one frame big and shows the strip as its background. The animation moves the background left, one frame at a time.

<div class="coin"></div>

.coin {
  width: 32px;
  height: 32px;
  background: url(coin-spin-strip.png) 0 0 no-repeat;
  animation: coin-spin 0.8s steps(8) infinite;
}

@keyframes coin-spin {
  from { background-position: 0 0; }
  to   { background-position: -256px 0; }
}

Three numbers have to agree with the sheet:

• The element is one frame: 32 × 32 pixels.
• steps(8) is the number of frames. Without it the background would glide smoothly past the frames. With it, the move is cut into 8 equal jumps of 32 pixels.
• The duration is frames ÷ frame rate: 8 frames at 10 frames per second = 0.8 s. How Fast Should Pixel Art Animate? helps you pick the rate.

Now look at the end value. It is −256px, the full width of the strip, not −224px, the position of the last frame. The next section shows why that matters.

Why frames slide or skip: the end-value rule

steps(8) cuts the move from the start value to the end value into 8 equal parts, and by default it shows the value at the start of each part. Sampled at the middle of each 100 ms slice, to -256px shows 0, −32, −64 and so on to −224: every frame, once each. The end value itself, an empty spot just past the strip, would only be reached at the very end of the cycle. That is exactly when the loop starts over at 0, so it never shows.

Both classic mistakes come from ending on the last frame's position instead:

The rule: steps(N), with the end value at −(N × frame width). A sprite that drifts sideways while it plays means the end value is short. An animation that always seems to miss its last drawing means N is one too small.

jump-start, jump-end, jump-none and jump-both

steps() takes an optional second argument that says where the jumps fall (MDN's steps() reference lists four options), and steps(8) is short for steps(8, jump-end). With jump-end, the last jump happens when the cycle ends. With jump-start, the first jump happens when it begins. jump-none puts neither jump at the edges, and jump-both puts jumps at both. Here is what each one shows on the coin strip:

• jump-end (the default) is the one for loops.
• jump-start jumps as soon as the cycle starts, so frame 1 is skipped, and the last slice shows −256px, the empty spot past the strip. The sprite blinks out once per loop.
• jump-none makes 8 steps that include both ends: the start value and the end value each get a full slice.
• jump-both makes 8 positions 28.4 px apart (256 ÷ 9), so it never lines up with 32 px frames. It has no use for sprite sheets.

jump-none is the one for an animation that plays once and stops on its last frame, like a chest opening or a one-off burst. End on the last frame's position this time, and add forwards so the animation stays there when it finishes:

.play-once {
  width: 32px;
  height: 32px;
  background: url(coin-spin-strip.png) 0 0 no-repeat;
  animation: play-once 0.8s steps(8, jump-none) forwards;
}

@keyframes play-once {
  to { background-position: -224px 0; }
}

Do the same with the default jump-end and the animation finishes on −256px, so the sprite vanishes the moment it ends.

The jump keywords work in Chrome 77, Firefox 65 and Safari 14 and later. The older start and end spellings mean the same as jump-start and jump-end.

Sheets with more than one row

The bouncing-ball sample, ball-bounce.png, has 8 frames of 64 × 64 pixels in 4 columns and 2 rows (256 × 128 pixels). There are two ways to play it.

Two animations, one walking across the columns and one walking down the rows:

.ball {
  width: 64px;
  height: 64px;
  background: url(ball-bounce.png) 0 0 no-repeat;
  animation:
    ball-x 0.4s steps(4) infinite,
    ball-y 0.8s steps(2) infinite;
}

@keyframes ball-x { to { background-position-x: -256px; } }
@keyframes ball-y { to { background-position-y: -128px; } }

The column animation takes one row's worth of time (4 frames × 0.1 s) and repeats. The row animation takes the whole cycle, 0.8 s, and steps down once halfway through. The end-value rule still holds: the full width and the full height. Sampled live in Chromium, this plays frames 1 to 8 in reading order. It only works when every row is full, though. With 7 frames in a 4 × 2 grid, the empty eighth cell would flash once per loop.

One keyframe per frame works with any layout, including a half-empty last row, and it lets you time each frame separately. In a CSS animation, the timing function applies between each pair of keyframes, so steps(1) holds each keyframe's value until the next one:

.ball-hold {
  width: 64px;
  height: 64px;
  background: url(ball-bounce.png) 0 0 no-repeat;
  animation: bounce 1s steps(1) infinite;
}

@keyframes bounce {
  0%  { background-position: 0 0; }         /* held for 300 ms */
  30% { background-position: -64px 0; }
  40% { background-position: -128px 0; }
  50% { background-position: -192px 0; }
  60% { background-position: 0 -64px; }     /* the squash */
  70% { background-position: -64px -64px; }
  80% { background-position: -128px -64px; }
  90% { background-position: -192px -64px; }
}

Each percentage is the moment that frame appears. Here the ball hangs at the top for 300 ms, then every other frame gets 100 ms. Holding key poses like this is what makes an animation feel weighted instead of mechanical.

Scale it up without blur

Pixel art at 32 pixels is tiny on a modern screen. To show it 4× larger, multiply every pixel number by 4 (the element, the size of the sheet and the end value) and switch off smoothing:

.coin-4x {
  width: 128px;    /* 32 × 4 */
  height: 128px;
  background: url(coin-spin-strip.png) 0 0 / 1024px 128px no-repeat;
  image-rendering: pixelated;
  animation: coin-spin-4x 0.8s steps(8) infinite;
}

@keyframes coin-spin-4x {
  to { background-position: -1024px 0; }
}

• / 1024px 128px in the shorthand is background-size: the 256 × 32 sheet drawn at 4×. The end value is the new strip width, 8 × 128 = 1024.
• image-rendering: pixelated tells the browser to scale with nearest-neighbor instead of blending. In a Chromium screenshot of the first frame, the pixelated coin uses only the 7 colors drawn in the sheet. Without it, the same screenshot has 336 colors, most of them blends along the edges. It works in Chrome 41, Firefox 93, Safari 10 and later.
• Use whole-number scales (2×, 3×, 4×) so every art pixel covers the same number of screen pixels. For more on this, see How to Scale Pixel Art Without Blurring It.

Pause it, and respect reduced motion

Two small rules make a looping sprite friendlier: one freezes it under the mouse, the other turns it off for visitors who have asked for less motion.

.coin:hover {
  animation-play-state: paused;
}

@media (prefers-reduced-motion: reduce) {
  .coin {
    animation: none;
  }
}

A paused CSS animation resumes from where it stopped. In the test, the hovered coin held its frame for as long as the mouse stayed on it, then carried on with the next frame when the mouse left.

prefers-reduced-motion: reduce matches when the visitor has turned on the reduce-motion setting of their operating system. macOS, iOS, Windows, Android and the main Linux desktops all have one. With animation: none, the element falls back to its own background-position, so it shows frame 1. To rest on a better pose, set a different position in the same rule, such as background-position: -64px 0 for frame 3.

Getting a strip and its positions from SpritePilot

If your sheet has several rows or gaps between frames, SpritePilot can turn it into a plain strip. Cut it into frames with Grid Slice in Sprite Detection, then open Export & Download and choose Horizontal Strip under Sprite Sheet Layout, PNG as the image format and CSS Sprites as the metadata. You get sprite-sheet.png plus sprite-sheet.css.

The CSS file isn't an animation. It holds a .sprite base class and one class per frame with that frame's position and size:

.sprite { display: inline-block; box-sizing: content-box; background-image: url('sprite-sheet.png'); background-repeat: no-repeat; background-origin: content-box; background-clip: content-box; }
.sprite-sprite_0001 { background-position: -0px -0px; width: 32px; height: 32px; }
.sprite-sprite_0002 { background-position: -32px -0px; width: 32px; height: 32px; }

That makes a good base for an animation. The first frame's class gives the element its size and its resting frame, and the animation does the rest:

<div class="sprite sprite-sprite_0001 coin"></div>

.coin { animation: coin-spin 0.8s steps(8) infinite; }

@keyframes coin-spin { to { background-position: -256px 0; } }

While the animation runs, it overrides the class's background-position; with reduced motion on, the class shows frame 1. Leave Trim transparency off for animation frames: trimmed frames are centered in their cells, so any sprite that isn't symmetrical shifts from frame to frame. To find the right speed before you write it into the duration, play the sheet in the Sprite Player and move its speed slider anywhere from 1 to 60 fps. Grid Slice, Export & Download and the Sprite Player all run in your browser; nothing is uploaded.

A checklist

• The element is one frame: width and height of a single frame.
• steps(N), where N is the number of frames in the row.
• End value = −(N × frame width): the full strip, not the last frame.
• Duration = N ÷ frames per second.
• Play once and stop: steps(N, jump-none), end on the last frame, add forwards.
• Several rows: two animations if every row is full, otherwise one keyframe per frame with steps(1).
• Bigger: multiply every number by a whole-number scale and add image-rendering: pixelated.
• Add a prefers-reduced-motion rule that turns the animation off.

This walkthrough builds it piece by piece: loading the sheet, cutting frames, an Animation class that runs at the same speed at any frame rate, several animations from one sheet, flipping, crisp scaling and sprite groups. It follows the pygame 2.6 documentation, and the pieces add up to one complete program.

Load the sheet and cut out the frames

You need two numbers first: the frame size and how fast the animation should play. If the sheet came without them, load it into SpritePilot's Sprite Player, enter the columns and rows, and it shows the frame size and plays the animation at any speed from 1 to 60 FPS. The coin strip used here is 256 × 32 pixels with 8 frames, so each frame is 32 × 32, and it looks right at 10 FPS.

import pygame

pygame.init()
screen = pygame.display.set_mode((640, 360))

sheet = pygame.image.load("coin-spin-strip.png").convert_alpha()
frames = [sheet.subsurface((i * 32, 0, 32, 32)) for i in range(8)]

Two calls do the work:

• convert_alpha() makes a copy of the image in the window's pixel format, keeping per-pixel transparency, so it draws quickly. Because it converts to the window's format, call it after pygame.display.set_mode().
• subsurface(rect) returns a Surface for one rectangle of the sheet. As the documentation explains, it shares its pixels with the sheet, so cutting a sheet into 100 frames copies nothing. If you plan to edit frames individually, blit each one into its own pygame.Surface((32, 32), pygame.SRCALPHA) instead.

A function for any grid

Real sheets have several rows and sometimes a border (margin) or gaps (spacing). This function handles all of them and returns the frames row by row. Save it, and every piece after it, in one file, game.py, next to the PNGs:

import pygame

SCALE = 4  # draw the 32 x 32 pixel art four times larger


def slice_grid(sheet, frame_w, frame_h, margin=0, spacing=0):
    """Cut a sheet into rows of frames. Each frame shares the sheet's pixels."""
    cols = (sheet.get_width() - 2 * margin + spacing) // (frame_w + spacing)
    rows = (sheet.get_height() - 2 * margin + spacing) // (frame_h + spacing)
    return [
        [
            sheet.subsurface((margin + c * (frame_w + spacing),
                              margin + r * (frame_h + spacing),
                              frame_w, frame_h))
            for c in range(cols)
        ]
        for r in range(rows)
    ]


def enlarge(frames, factor=SCALE):
    """Nearest-neighbor scaling: crisp at whole-number factors."""
    return [pygame.transform.scale(f, (f.get_width() * factor, f.get_height() * factor))
            for f in frames]

For a sheet with a 4-pixel border and 2-pixel gaps, call slice_grid(sheet, 32, 32, margin=4, spacing=2). If you don't know those numbers, How to Find the Frame Size of a Sprite Sheet shows how to work them out. enlarge() is explained under scaling below.

An Animation class that keeps time

The simplest version adds 1 to the frame index on every pass through the game loop. At 60 loops a second, an 8-frame coin then spins seven and a half times a second, and on a 144 Hz monitor it spins faster still. The animation's speed has to come from elapsed time, not from the number of loops.

Pygame gives you the elapsed time for free: clock.tick() returns the milliseconds since its previous call. The class adds those up and moves to the next frame each time a frame's worth of time has passed:

class Animation:
    """A list of frames played at a fixed rate, driven by elapsed milliseconds."""

    def __init__(self, frames, fps, loop=True):
        self.frames = frames
        self.mirrored = [pygame.transform.flip(f, True, False) for f in frames]
        self.frame_ms = 1000 / fps
        self.loop = loop
        self.reset()

    def reset(self):
        self.index = 0
        self.elapsed = 0.0
        self.done = False

    def update(self, dt_ms):
        if self.done:
            return
        self.elapsed += dt_ms
        while self.elapsed >= self.frame_ms:
            self.elapsed -= self.frame_ms
            if self.index < len(self.frames) - 1:
                self.index += 1
            elif self.loop:
                self.index = 0
            else:
                self.done = True
                break

    def current(self, flipped=False):
        return (self.mirrored if flipped else self.frames)[self.index]

Three details matter. Subtracting frame_ms instead of resetting elapsed to 0 carries the leftover milliseconds into the next frame, so the timing doesn't drift. The while loop catches up if one slow frame took longer than a whole animation frame. And loop=False makes a one-shot animation, such as an attack, stop on its last frame and set done.

Several animations in one sheet

The slime sheet holds three animations, one per row: idle (4 frames), hop (6) and attack (5). The rows have different lengths, so slice the whole grid and trim each row to its frame count. The same file also needs a coin:

class Coin(pygame.sprite.Sprite):
    def __init__(self, sheet, pos):
        super().__init__()
        frames = enlarge(slice_grid(sheet, 32, 32)[0])  # one row of 8 frames
        self.anim = Animation(frames, fps=10)
        self.image = self.anim.current()
        self.rect = self.image.get_rect(center=pos)

    def update(self, dt_ms, *args):
        self.anim.update(dt_ms)
        self.image = self.anim.current()


class Slime(pygame.sprite.Sprite):
    SPEED = 120  # pixels per second

    def __init__(self, sheet, pos):
        super().__init__()
        idle, hop, attack = slice_grid(sheet, 32, 32)  # one animation per row
        self.anims = {
            "idle": Animation(enlarge(idle[:4]), fps=6),
            "hop": Animation(enlarge(hop), fps=10),
            "attack": Animation(enlarge(attack[:5]), fps=12, loop=False),
        }
        self.state = "idle"
        self.facing_left = False
        self.x = float(pos[0])
        self.image = self.anims["idle"].current()
        self.rect = self.image.get_rect(midbottom=pos)

    def play(self, state):
        if state != self.state:
            self.state = state
            self.anims[state].reset()

    def update(self, dt_ms, move, attack_pressed):
        if self.state != "attack":
            if attack_pressed:
                self.play("attack")
            elif move:
                self.facing_left = move < 0
                self.x += move * self.SPEED * dt_ms / 1000
                self.play("hop")
            else:
                self.play("idle")

        anim = self.anims[self.state]
        anim.update(dt_ms)
        if anim.done:  # a one-shot animation finished
            self.play("idle")
            anim = self.anims["idle"]

        bottom = self.rect.bottom
        self.image = anim.current(self.facing_left)
        self.rect = self.image.get_rect(midbottom=(round(self.x), bottom))

play() restarts an animation only when the state actually changes, so calling it every frame keeps a running animation going. Movement uses the same elapsed time as the animation, so the slime crosses the screen at 120 pixels per second at any frame rate. The rectangle is re-anchored at the bottom center each frame, which keeps the slime's feet in place even if frames had different sizes.

Flip and scale once, at load time

The slime is drawn facing right. For left, pygame.transform.flip(surface, True, False) returns a mirrored copy, so the Animation class builds the mirrored frames once, in __init__, and current(flipped=True) picks them. Flipping every frame would allocate a new Surface 60 times a second for nothing.

Scaling works the same way: once, when loading. The function you choose decides how pixel art looks:

• scale() is a fast resize that, in the documentation's words, "does not sample the results": each source pixel is copied, so at 2×, 3× or 4× every pixel becomes a clean square block. This is the one for pixel art.
• smoothscale() uses a bilinear filter when enlarging, which blends neighboring pixels and blurs hard edges. Keep it for photos and painted art.
• scale_by(surface, 4), added in pygame 2.1.3, is scale() with a factor instead of a size. The documentation still marks it experimental.

Whatever the function, stick to whole-number factors: at 1.5× some pixels come out one pixel wide and others two. How to Scale Pixel Art Without Blurring It covers the same problem in other tools.

Draw everything with a sprite group

A pygame.sprite.Group calls update() on every sprite with whatever arguments you pass it, and its draw() blits each sprite's image at its rect. That's why both classes keep those two attributes up to date. The last piece is the game loop:

def main():
    pygame.init()
    screen = pygame.display.set_mode((640, 360))
    clock = pygame.time.Clock()

    # convert_alpha() converts to the window's pixel format, so call it after set_mode()
    coin_sheet = pygame.image.load("coin-spin-strip.png").convert_alpha()
    slime_sheet = pygame.image.load("slime-sheet.png").convert_alpha()
    sprites = pygame.sprite.Group(Coin(coin_sheet, (480, 150)), Slime(slime_sheet, (200, 300)))

    running = True
    while running:
        dt = clock.tick(60)  # milliseconds since the previous frame
        attack = False
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                running = False
            elif event.type == pygame.KEYDOWN and event.key == pygame.K_SPACE:
                attack = True

        keys = pygame.key.get_pressed()
        move = keys[pygame.K_RIGHT] - keys[pygame.K_LEFT]

        sprites.update(dt, move, attack)
        screen.fill((31, 41, 55))
        sprites.draw(screen)
        pygame.display.flip()

    pygame.quit()


if __name__ == "__main__":
    main()

clock.tick(60) both limits the loop to 60 frames a second and returns the time since the last frame, which is the dt every sprite receives. The arrow keys move the slime, which hops and turns to face its direction; Space attacks once. A plain Group draws its sprites in no particular order, so if sprites overlap and the order matters, use pygame.sprite.LayeredUpdates instead.

A checklist

• convert_alpha() every sheet, after set_mode().
• One subsurface() per frame; separate Surfaces only if you edit frames.
• Advance frames by elapsed milliseconds from clock.tick(), never once per loop.
• Flip and scale when loading, with scale() at whole-number factors.
• Keep image and rect current, and let a group update and draw.

Both sheets are free to use in any project (CC0): the coin strip (256 × 32, 8 frames) and the slime sheet (192 × 96, three rows of 32 × 32 frames). Save them next to game.py and run it. The same slime is animated in Godot 4, Unity and Phaser too. For more, the Free Pixel Art Game Assets page has 70 animated CC0 strips, such as pickups and creatures, that slice with the same code.

This article loads the same character both ways, builds its animations, and covers playing, flipping and reacting to animation events. Everything here works in Phaser 3.60 and later, including Phaser 4; the details were checked against the Phaser source.

Sprite sheet or atlas?

A sprite sheet, in Phaser's terms, is one image where every frame is the same size on a grid. There is no data file: you tell Phaser the frame size, and it numbers the cells 0, 1, 2… left to right, top to bottom.

A texture atlas is an image plus a JSON file that lists each frame's name and rectangle. Frames can be any size, trimmed of empty space and packed tightly, and one atlas can hold a whole character, or several.

Use a sprite sheet when all frames share one size and you want no extra files: one character, a prototype, a sheet from an artist. Use an atlas when frames vary in size, when trimming saves real space, when you'd rather write 'attack_0002.png' than remember that the attack starts at frame 12, or when you want many sprites in one texture.

Loading a sprite sheet

preload() {
  this.load.spritesheet('slime-grid', 'assets/slime-sheet.png', {
    frameWidth: 32,
    frameHeight: 32,
  })
}

The frame config takes six options:

• frameWidth is required; frameHeight defaults to the same value.
• margin is a border around the whole sheet, and spacing is the gap between frames. If the frame size doesn't divide the image evenly, the sheet probably has one or both; How to Find the Frame Size of a Sprite Sheet shows how to work them out.
• startFrame and endFrame load only part of the grid. The frames you keep are numbered from 0 again, so startFrame: 6 makes the seventh cell frame 0.

Empty cells get numbers too. In the slime sheet above, idle is frames 0–3, cells 4 and 5 are empty, hop is 6–11 and attack is 12–16. Forget them and every animation after them is off by two frames.

Loading an atlas

preload() {
  this.load.atlas('slime', 'assets/sprite-sheet.png', 'assets/sprite-sheet.phaser.json')
}

Phaser reads both TexturePacker layouts, the JSON Hash (frames as an object) and the JSON Array (frames as a list), and detects which one you gave it. SpritePilot's Export & Download writes both: its Phaser 3 format is the array and its TexturePacker format is the hash. Here is one frame from the slime atlas:

{
  "filename": "hop_0001.png",
  "rotated": false,
  "trimmed": true,
  "sourceSize": { "w": 32, "h": 32 },
  "spriteSourceSize": { "x": 1, "y": 16, "w": 30, "h": 14 },
  "frame": { "x": 0, "y": 32, "w": 30, "h": 14 },
  "pivot": { "x": 0.5, "y": 1 }
}

Three fields do useful work in Phaser:

• filename is the frame's name. SpritePilot uses the names you type under Rename & Reorder Sprites, plus .png; untouched frames are sprite_0001.png, sprite_0002.png and so on.
• sourceSize and spriteSourceSize describe the trimming. Phaser puts the 30 × 14 pixels back at their place in the original 32 × 32 frame, so trimmed frames don't jump around.
• pivot becomes the sprite's origin. With the pivot at bottom center (0.5, 1), a sprite's x and y mark the bottom center of its frame, where a character's feet usually are, which makes placing characters on the ground easy.

Building animations: frame numbers or frame names

For a sprite sheet, generateFrameNumbers turns a range into frames:

this.anims.create({
  key: 'hop',
  frames: this.anims.generateFrameNumbers('slime-grid', { start: 6, end: 11 }),
  frameRate: 10,
  repeat: -1,
})

For an atlas, generateFrameNames builds each name from a prefix, a zero-padded number and a suffix, so this produces attack_0001.png to attack_0005.png:

this.anims.create({
  key: 'attack',
  frames: this.anims.generateFrameNames('slime', {
    prefix: 'attack_',
    start: 1,
    end: 5,
    zeroPad: 4,
    suffix: '.png',
  }),
  frameRate: 12,
})

If a name doesn't exist, Phaser logs Frame "attack_1.png" not found in texture "slime" and leaves that frame out. The usual suspects are a missing suffix: '.png' and a wrong zeroPad. Both helpers also take a frames array, such as frames: [6, 7, 8, 7], when the order isn't a simple range.

The rest of the config:

• frameRate defaults to 24 when you give neither it nor a duration, which is fast for pixel art. How Fast Should Pixel Art Animate? has better starting points.
• repeat: -1 loops forever; leave it out for one-shot animations. yoyo: true plays forward, then backward.
• Animations are global. this.anims is the game's Animation Manager, so an animation created in one scene can be played by sprites in any scene. Create each key once; creating it again only logs a warning and returns the existing one.

Shortcut: SpritePilot's animation tags

If you define Animation Tags in SpritePilot's Export (idle 0–3, hop 4–9, attack 10–14), they're written into the JSON's meta.frameTags. Phaser keeps the JSON's extra data in texture.customData, and getFrameNames() returns the frames in the order the JSON lists them, so you can build every animation in one loop:

const texture = this.textures.get('slime')
const names = texture.getFrameNames()
for (const tag of texture.customData.meta?.frameTags ?? []) {
  this.anims.create({
    key: tag.name,
    frames: names.slice(tag.from, tag.to + 1).map(frame => ({ key: 'slime', frame })),
    frameRate: 10,
    repeat: -1,
    yoyo: tag.direction === 'pingpong',
  })
}

Override one-shot animations when you play them, for example sprite.play({ key: 'attack', repeat: 0 }).

Playing, flipping and listening

create() {
  // create the idle, hop and attack animations first (see above)
  this.slime = this.add.sprite(160, 120, 'slime', 'idle_0001.png')
  this.cursors = this.input.keyboard.createCursorKeys()
  this.attacking = false
  this.slime.on('animationcomplete-attack', () => {
    this.attacking = false
  })
}

update() {
  const { left, right, space } = this.cursors
  if (this.attacking) return

  if (Phaser.Input.Keyboard.JustDown(space)) {
    this.attacking = true
    this.slime.play('attack')
  } else if (left.isDown || right.isDown) {
    this.slime.setFlipX(left.isDown)
    this.slime.play('hop', true)
  } else {
    this.slime.play('idle', true)
  }
}

The true in play('hop', true) is ignoreIfPlaying. Without it, each call restarts the animation, so a play() inside update() shows only the first frame forever. The attack call leaves it out on purpose, so a new attack always starts from its first frame.

animationcomplete-attack is the per-key form of the animationcomplete event. It fires only for animations with a finite repeat count; an animation with repeat: -1 never completes. To react to a particular frame, such as a hit or a footstep, listen for animationupdate; its listener receives the animation and the current frame, and frame.textureFrame is the frame's name or number.

For pixel art, add pixelArt: true to the game config. Phaser's documentation says it turns antialiasing off and roundPixels on, which keeps scaled sprites crisp.

What about load.aseprite?

this.load.aseprite('paladin', 'paladin.png', 'paladin.json') followed by this.anims.createFromAseprite('paladin') turns every tag in an Aseprite export into an animation, with Aseprite's frame durations, reverse and ping-pong directions. The catch is in the source: createFromAseprite looks frames up by their number, "0", "1" and so on. That only works if you exported from Aseprite with the Item Filename field set to just {frame}, as the Phaser source comments explain. Files that copy Aseprite's layout but give their frames names, such as SpritePilot's Aseprite JSON, load fine with load.atlas instead.

Checklist

• Same-size frames and no data file: load.spritesheet with generateFrameNumbers, and count the empty cells.
• Trimmed, packed or named frames: load.atlas with generateFrameNames, including the .png suffix and the zero padding.
• Inside update(), use play(key, true).
• One-shot animations: no repeat, then animationcomplete-<key>.
• Pixel art: pixelArt: true.

The files from this article are free to use in any project (CC0): the grid sheet (192 × 96, 32 × 32 frames), and SpritePilot's atlas export of the same frames, sprite-sheet.png with sprite-sheet.phaser.json. For a step-by-step export, see How to Export a Phaser Texture Atlas from SpritePilot. The same slime is animated in Godot 4, Unity and pygame too. Seventy more animated CC0 sprites are on the Free Pixel Art Game Assets page; every strip loads with load.spritesheet and the frame size in its file name.

1. Import settings that keep pixel art crisp

Drop the PNG into your project, select it, and set these in the Inspector before anything else:

Press Apply. Use the same Pixels Per Unit for every sprite in the game, so characters and tiles stay to scale, and leave Generate Mipmap (under Advanced) off for 2D art. If lines appear between your tiles later, Why Lines Appear Between Your Tiles covers the remaining fixes.

2. Slice the sheet in the Sprite Editor

Slicing needs the frame size. If the sheet came without notes, load it into SpritePilot's Sprite Player first and enter the columns and rows: it reports the frame size, warns about leftover pixels, and plays the animation so you can check the speed before you set anything in Unity.

Then click Open Sprite Editor in the texture's Inspector (if it says Install 2D Sprite Package instead, click that first) and choose Slice:

1. Type: Grid By Cell Size.
2. Pixel Size: the frame size, 32 × 32 here.
3. Offset: the border around the sheet, if there is one. Padding: the gap between frames. Both are 0 for this sheet.
4. Pivot: Bottom, so the GameObject's position sits at the bottom center of every frame. Characters then stand on their position, and frames of different poses line up.
5. Keep Empty Rects: off, so the three empty cells don't become sprites.
6. Click Slice, then Apply in the toolbar.

Grid By Cell Count takes columns and rows instead, which is fine for a sheet without gaps. For one with a margin and spacing, Grid By Cell Size with Offset and Padding is the reliable choice; How to Find the Frame Size of a Sprite Sheet shows how to work those numbers out. The sliced sprites appear as children of the texture in the Project window.

3. Make one clip per animation

Unity has a shortcut for the first clip. Expand the texture in the Project window, select the four idle sprites and drag them into the Scene view. Unity asks where to save the new clip, then creates a GameObject with a Sprite Renderer and an Animator, a clip containing those frames at 12 samples per second, and an Animator Controller that plays the clip. It orders the frames by name in natural order, so a sprite ending in _2 comes before one ending in _10.

For the other animations, keep that GameObject selected and open Window → Animation → Animation (Ctrl+6, or Cmd+6 on a Mac). Pick Create New Clip from the clip menu under the playback controls, save it as run, and drag the six hop sprites onto the timeline. Do the same for attack. Each new clip is added to the same controller as a new state.

Now set the speed. Each sprite key sits one sample apart, so the clip's sample rate is its frame rate. Open the Animation window's ⋮ menu, turn on Show Sample Rate, and set each clip's sample rate (the Samples field): 6 for idle, 10 for run and 12 for attack are good starting points. Clips created in the Animation window start at 60, which plays a 6-frame hop in a tenth of a second. To hold one drawing longer, drag the keys after it to the right; How Fast Should Pixel Art Animate? covers the timing choices.

Last, select attack.anim in the Project window and untick Loop Time. Unity creates every new clip with looping on, and an attack should play once.

4. Wire the states in the Animator

Open the controller (double-click it) and add two parameters in the Parameters tab: Speed (Float) and Attack (Trigger). Then right-click a state, choose Make Transition, and click the target state:

• Idle → Run: condition Speed Greater 0.1.
• Run → Idle: condition Speed Less 0.1.
• Idle → Attack and Run → Attack: condition Attack.
• Attack → Idle: no conditions.

Now the two settings that matter most for sprites. On every transition except Attack → Idle, untick Has Exit Time and set Transition Duration to 0 under Settings. With Has Exit Time on, Unity waits until the clip reaches its exit time before it even checks the conditions, so the character keeps running after you let go. And a sprite can't be half one drawing and half another, so a blend has nothing useful to do; a duration of 0 switches drawings at once.

Attack → Idle is the exception: leave Has Exit Time on with Exit Time 1, so the whole attack plays before the character returns to Idle.

A trigger stays set until a transition uses it. Press attack during an attack and a second one plays right after; call ResetTrigger("Attack") when the first attack starts if you don't want that buffering.

5. Drive it from a script

Add this script to the GameObject. RequireComponent adds a Rigidbody2D if it's missing; set its Gravity Scale to 0 for a top-down game.

using UnityEngine;
using UnityEngine.InputSystem;

[RequireComponent(typeof(Rigidbody2D), typeof(Animator), typeof(SpriteRenderer))]
public class SlimeController : MonoBehaviour
{
    [SerializeField] float moveSpeed = 3f;
    [SerializeField] Collider2D hitbox; // a trigger collider on a child object

    static readonly int SpeedId = Animator.StringToHash("Speed");
    static readonly int AttackId = Animator.StringToHash("Attack");

    Rigidbody2D body;
    Animator animator;
    SpriteRenderer spriteRenderer;
    InputAction moveAction;
    InputAction attackAction;

    void Awake()
    {
        body = GetComponent<Rigidbody2D>();
        animator = GetComponent<Animator>();
        spriteRenderer = GetComponent<SpriteRenderer>();
        moveAction = InputSystem.actions.FindAction("Move");
        attackAction = InputSystem.actions.FindAction("Attack");
    }

    void Update()
    {
        float x = moveAction.ReadValue<Vector2>().x;
        body.linearVelocity = new Vector2(x * moveSpeed, body.linearVelocity.y);

        animator.SetFloat(SpeedId, Mathf.Abs(x));
        if (x != 0f)
            spriteRenderer.flipX = x < 0f;

        if (attackAction.WasPressedThisFrame())
            animator.SetTrigger(AttackId);
    }

    // Called by Animation Events on the attack clip
    public void HitboxOn() => hitbox.enabled = true;
    public void HitboxOff() => hitbox.enabled = false;
}

A few Unity 6 details are built in here:

• Input: Unity 6 projects use the Input System package, and the script reads its default Move and Attack actions, as in the package's quick start guide. If your project has no project-wide actions yet, create them under Edit → Project Settings → Input System Package → Input Actions. Older scripts that read Input.GetAxis throw an error in a project set to use only the new system.
• Velocity: Unity 6 renamed Rigidbody2D.velocity to linearVelocity; the old name still compiles but is marked obsolete.
• Flipping: flipX mirrors the drawing only. Unity's reference says to use a negative Transform scale when colliders should flip too, so a hitbox on a child object needs its own mirroring.
• Parameter IDs: Animator.StringToHash turns the names into IDs once, instead of looking up the strings every frame.

The two hitbox methods are for Animation Events. Put a trigger collider on a child object, disable it, and drag it into the script's Hitbox field. Then open attack.anim, move the playhead to the lunge frame, click the Event button, and choose HitboxOn in the Inspector's Function field. Add HitboxOff on the recovery frame. The Animation Event page lists what such a method may take: no parameter, or one float, int, string, object reference or AnimationEvent. The same trick plays footstep sounds on exactly the frame a foot lands.

Checklist

• Import: Sprite (2D and UI), Multiple, Point (no filter), Compression None, consistent Pixels Per Unit.
• Slice: Grid By Cell Size, with Offset for a border and Padding for gaps; Pivot Bottom for characters.
• Clips: Samples equals frames per second; Loop Time off for one-shot animations.
• Transitions: Has Exit Time off and Transition Duration 0, except the one leaving a one-shot animation.
• Script: Input System actions, linearVelocity, flipX for the drawing only.

Unity doesn't read atlas JSON files on its own, so this workflow uses a grid sheet. For trimmed or mixed-size frames, How to Export Sprites from SpritePilot for Unity shows how to bring them in as separate sprites instead. The slime sheet from this article is free to use in any project (CC0): download slime-sheet.png, 192 × 96, six columns and three rows of 32 × 32 frames. The same sheet is set up in Godot 4, Phaser and pygame too. More free sprites to practice with, all one-row strips that slice with Grid By Cell Size: Free Pixel Art Game Assets.

This article explains the difference, sets both up from the same sheet, and gives you the GDScript that drives them. It applies to all of Godot 4; the one feature that is new in Godot 4.7 is marked.

Which one to use

AnimatedSprite2D plays a SpriteFrames resource: named animations, each a list of frames with its own speed. AnimationPlayer is a general timeline. Point it at a Sprite2D and it can key the sprite's frame number, plus any other property, method call or sound at an exact time.

A good rule: start with AnimatedSprite2D. Move an animation to AnimationPlayer when something besides the picture has to change on a particular frame: a hitbox during a swing, a footstep sound, a muzzle flash. The two also combine, since an AnimationPlayer can key an AnimatedSprite2D's properties too.

Set up AnimatedSprite2D from a sheet

The example is a 192 × 96 slime sheet (free to download at the end): three rows of 32 × 32 frames for idle (4 frames), hop (6) and attack (5).

1. Add an AnimatedSprite2D node. In the Inspector, click its empty Sprite Frames property, choose New SpriteFrames, then click the new resource. The SpriteFrames panel opens at the bottom of the editor.
2. Double-click the default animation and rename it idle.
3. Click Add Frames from Sprite Sheet (the grid icon above the frame list; Ctrl+Shift+O, or Cmd+Shift+O on a Mac) and pick the PNG.
4. In the Select Frames dialog, set Horizontal to 6 and Vertical to 3. Click the four idle frames, then Add 4 Frame(s).
5. Set the speed in the FPS box beside the animation list; new animations start at 5 FPS. The Animation Looping button next to it turns looping on or off. In Godot 4.7 it has a third state, ping-pong.
6. Click Add Animation and repeat for hop and attack.

Two settings in the panel do most of the timing work. FPS sets the base speed, and Frame Duration stretches individual frames. Frame Duration is relative, and the SpriteFrames documentation gives the formula: seconds on screen = duration ÷ (FPS × playing speed). At 10 FPS, a frame with duration 1.0 shows for 0.1 s and one with 3.0 holds for 0.3 s, which is how you give an attack a pause before the strike. For choosing the numbers, see How Fast Should Pixel Art Animate?

Sheets with a border or gaps

If the sheet has a border around it (a margin) or gaps between frames (spacing), the dialog's other fields matter: Size is the frame size, Separation is the gap and Offset is the border. The order you fill them in decides the result.

When you type Horizontal and Vertical, Godot works out the size by dividing what's left of the image after the Offset and the gaps. The Offset only comes off the left and top, so the border on the right and bottom is counted as frame. On this 142 × 74 coin sheet that gives 33 × 34 frames, and each cut lands a little further off target. Type Size first instead (32 × 32), then Separation (2) and Offset (4), and Godot works out the counts itself. If you don't know the numbers, How to Find the Frame Size of a Sprite Sheet shows how to work them out.

Play, switch and flip from GDScript

This character idles, hops while moving and attacks once on a key press:

extends CharacterBody2D

const SPEED := 120.0

@onready var sprite: AnimatedSprite2D = $AnimatedSprite2D

var attacking := false


func _ready() -> void:
	sprite.animation_finished.connect(_on_animation_finished)


func _physics_process(_delta: float) -> void:
	var direction := Input.get_axis("ui_left", "ui_right")
	velocity.x = direction * SPEED
	move_and_slide()

	if direction != 0.0:
		sprite.flip_h = direction < 0.0

	if attacking:
		return
	if Input.is_action_just_pressed("ui_accept"):
		attacking = true
		sprite.play("attack")
	elif direction != 0.0:
		sprite.play("hop")
	else:
		sprite.play("idle")


func _on_animation_finished() -> void:
	if sprite.animation == &"attack":
		attacking = false

Four details make this work:

• Calling play() every frame is safe. If the animation is already playing, play() with the same name carries on instead of restarting, so you don't need to check first.
• animation_finished never fires for a looping animation, as the AnimatedSprite2D reference notes. Turn looping off for attack, or the character stays stuck in it.
• flip_h mirrors the drawing only. Child nodes such as a hitbox keep their position, so mirror their position.x in the same place you set flip_h.
• Per-frame events need a signal. For a footstep, connect frame_changed and check sprite.animation and sprite.frame there. If you find yourself writing many of these checks, that animation belongs in an AnimationPlayer.

The AnimationPlayer route

Here the picture comes from a plain Sprite2D, and the AnimationPlayer changes its frame number on a timeline.

1. Add a Sprite2D and drag the sheet onto its Texture. Under Animation in the Inspector, set Hframes to 6 and Vframes to 3. Frames are numbered left to right, top to bottom from 0, so the attack row is frames 12 to 16. Sprite2D cuts the texture into equal cells, so it can't skip a border or gaps; give it a sheet without them.
2. Add an AnimationPlayer, open the Animation panel and choose Animation → New. Name it attack and set its length to 0.5 s: five frames at 10 FPS.
3. At the bottom of the panel, switch the snap step from Seconds to FPS and enter 10, so keys land every 0.1 s.
4. Select the Sprite2D and set Frame to 12. Click the key icon next to Frame and confirm the new track. Godot adds the key, raises Frame to 13 and moves the playhead one step. Click it four more times to key 13 to 16. The track is created in Discrete mode, so it jumps between whole frames instead of blending.
5. To sync gameplay, add a Call Method Track for the character node (Add Track → Call Method Track…). Right-click it at 0.1 s, choose Insert Key…, and pick enable_hitbox; insert disable_hitbox at 0.3 s. An Audio Playback Track can start the swipe sound at 0.1 s too.

The methods the track calls live in the character's script. Here the hitbox is an Area2D child named Hitbox:

func enable_hitbox() -> void:
	$Hitbox/CollisionShape2D.set_deferred("disabled", false)


func disable_hitbox() -> void:
	$Hitbox/CollisionShape2D.set_deferred("disabled", true)

set_deferred() is there because Godot's documentation says a collision shape's disabled property should be changed that way. Start the animation with $AnimationPlayer.play("attack") and listen for its animation_finished(anim_name) signal; like the AnimatedSprite2D signal, it never fires while the animation loops. One more trap from the 2D sprite animation tutorial: play() takes effect the next time the player processes. If you flip the sprite in the same frame and see one glitched frame, call advance(0) after play().

Exporting a ready-made SpriteFrames from SpritePilot

If you cut your sheet with SpritePilot's Grid Slice, or bring frames in from a GIF or the Pixel Art Editor, Export & Download can write the SpriteFrames resource for you. Choose SpriteFrames (Godot 4 .tres resource) and add an Animation Tag for each animation.

The download is the packed sheet, sprite-sheet.png, and sprite-frames.tres, a text resource that starts like this:

[gd_resource type="SpriteFrames" load_steps=17 format=3]

[ext_resource type="Texture2D" path="res://sprite-sheet.png" id="1"]

[sub_resource type="AtlasTexture" id="AtlasTexture_1"]
atlas = ExtResource("1")
region = Rect2(0, 0, 32, 32)

What's inside:

• One AtlasTexture per frame, pointing at that frame's rectangle in the sheet. With Trim transparency on, each also gets a margin that restores its original size, so trimmed frames don't shift.
• One animation per tag, using the frames from–to counted from 0 in the export order. With no tags you get a single animation called default containing every frame.
• 12 FPS, looping, duration 1.0 for every animation. Adjust them in the SpriteFrames panel afterwards, and switch looping off for attack. A tag's reverse or ping-pong direction is not carried into the file.

The resource expects the sheet at res://sprite-sheet.png, so put both files in the project root, or edit the path on the ext_resource line. Then load sprite-frames.tres into the AnimatedSprite2D's Sprite Frames property. The Godot import guide covers the JSON alternative.

A checklist

• Only the picture changes: AnimatedSprite2D.
• Something must happen on a specific frame: AnimationPlayer, or frame_changed in code for one or two cases.
• Sheet with a border: type the Size in the Select Frames dialog, not the counts.
• Anything you wait for, such as an attack or a death, must not loop.
• flip_h mirrors the drawing, not its children.
• For crisp pixel art, set the project's default texture filter to Nearest (why lines appear between tiles explains it).

The slime sheet is free to use in any project (CC0): download slime-sheet.png, 192 × 96, with idle in the top row (4 frames), hop in the middle row (6) and attack in the bottom row (5), all 32 × 32. Check its timing in the Sprite Player before you build the animations. The same sheet is set up in Unity, Phaser and pygame too. For more to practice with, the Free Pixel Art Game Assets page has 70 animated CC0 sprites, from creatures to effects, as one-row strips that load the same way: Horizontal = the frame count, Vertical = 1.

So "how fast should it animate?" is really two questions: how many drawings the animation has, and how long each one stays on screen. This article covers both, plus two traps that make a well-timed animation look wrong once it's in a game or a GIF.

Frame count, frame rate and duration

Three numbers describe an animation, and any two give you the third:

• frame count — how many drawings there are,
• frame rate — how many drawings are shown per second (fps),
• duration — how long one cycle takes: duration = frame count ÷ frame rate.

This is why "more frames" and "faster" are different fixes. If a walk looks choppy, add drawings and keep the duration. If it looks sluggish, raise the frame rate or cut frames — the cycle gets shorter either way.

What the frame rate does

Here is the same 8-frame coin at three frame rates:

At 5 fps you can see every drawing — fine for something slow, choppy for something that should move. At 20 fps the spin turns into a quick flash, and the individual drawings stop mattering. In between, at 10 fps, the coin spins at a pace the eye can follow while the pixel work still shows. That middle zone is where most pixel art lives.

These aren't rules, but they are common starting points in 2D games:

• Idle and breathing: 4–8 fps, often with long holds.
• Walk cycles: 8–12 fps.
• Runs: 10–15 fps — more speed comes from fewer, longer strides, not just a higher rate.
• Pickups and UI loops (coins, gems, blinking prompts): 8–15 fps.
• Effects (sparks, explosions, magic): 12–24 fps, often with frames of different lengths.

Set a starting rate, play it next to your character's movement speed, and adjust by eye. Feet that slide across the ground mean the animation and the movement don't match — change one of them.

Hold frames instead of using one rate

Real motion isn't evenly timed. An attack has a slow wind-up, a strike that's over almost instantly, and a recovery. Showing every frame for the same time makes it look mechanical. The fix is to time each drawing:

Every engine can do this:

• Godot 4: in the SpriteFrames panel, each frame has a Duration, and it is relative: 2.0 shows a frame twice as long as 1.0 at the animation's FPS. The documentation gives the exact rule: absolute duration = relative duration ÷ (animation FPS × playback speed).
• Phaser: give a frame a duration in milliseconds; in current versions, that is how long the frame stays on screen, and frames without one follow the animation's frameRate. (If you override the frame rate when calling play(), Phaser ignores the per-frame durations.)

this.anims.create({
  key: 'attack',
  frameRate: 12,
  frames: [
    { key: 'hero', frame: 0, duration: 100 },
    { key: 'hero', frame: 1, duration: 100 },
    { key: 'hero', frame: 2, duration: 200 }, // the hold
    { key: 'hero', frame: 3, duration: 40 },
    { key: 'hero', frame: 4, duration: 40 },
    { key: 'hero', frame: 5, duration: 80 },
    { key: 'hero', frame: 6, duration: 80 },
    { key: 'hero', frame: 7, duration: 80 },
  ],
})

• Unity: in the Animation window, a sprite stays on screen until the next keyframe, so you hold a drawing by moving the following keyframe later on the timeline. The clip's sample rate sets the grid the keyframes snap to.
• Aseprite: every frame has its own duration in milliseconds (Frame Properties), and its JSON export includes them.

The 60 Hz catch: some rates look uneven

A monitor shows a new image at a fixed rate — usually 60 times a second. Your animation can only change drawings on one of those refreshes, so a drawing is always on screen for a whole number of refreshes. When the frame rate divides 60 evenly, every drawing gets the same share. When it doesn't, some drawings get one refresh more than others:

The difference is small — a sixtieth of a second — but in a slow, smooth motion like a floating platform or a spinning coin it shows up as a faint stutter. On a 60 Hz screen, the even rates are 5, 6, 10, 12, 15, 20 and 30 fps.

Many players now have 120 Hz or 144 Hz screens, where the even rates are different (8 fps is even at 120 and 144 Hz, but not at 60). If you want a rate that is even on all three, pick 12, 6, 4, 3, 2 or 1 fps. That is one more reason 12 fps is such a popular choice.

GIFs round your timing

GIF stores each frame's time in hundredths of a second. Two consequences:

• Only some frame rates are exact. A GIF plays exactly at 100 ÷ n fps: 50, 33.3, 25, 20, 16.7, 14.3, 12.5, 11.1, 10 … — 12 and 24 fps aren't on the list. A 12 fps animation (0.083 s per frame) is stored as 0.08 s and plays at 12.5 fps.
• Very short delays get slower, not faster. Browsers treat a delay of 0 or 0.01 s as 0.1 s, so a "60 fps" GIF crawls along at 10 fps. The fastest reliable GIF is 0.02 s per frame — 50 fps.

SpritePilot's GIF export rounds to the nearest hundredth of a second and never goes below 0.02 s, so the GIF you download plays at the speed you expect. If exact timing matters, export an APNG instead: it stores each frame's time as a fraction (1/12 of a second), keeps full transparency, and plays in every modern browser.

Try it

Load a sheet into SpritePilot's Sprite Player, set its columns and rows, and drag the speed between 8, 10, 12 and 15 fps while it plays — the right rate is usually obvious within a few seconds. Ping-pong plays the frames forwards and back, which halves the drawings a breathing or hovering loop needs. The player runs in your browser and nothing is uploaded.

No sheet handy? The coin from this article is free to use (CC0): download the coin sheet, 8 frames of 32 × 32 pixels in a row. If you're not sure how a downloaded sheet is laid out, How to Find the Frame Size of a Sprite Sheet walks through it. The Free Pixel Art Game Assets page has 70 more, each with the speed it was timed for.

In short

• Duration = frame count ÷ frame rate. Choppy: add drawings. Sluggish: raise the rate or cut frames.
• Most pixel art sits between 8 and 12 fps; tune by eye against the movement.
• Time drawings individually for anything with weight — wind-ups, impacts, landings.
• On 60 Hz screens, rates that divide 60 play evenly; 12 fps is even at 60, 120 and 144 Hz.
• GIFs round to hundredths of a second and can't go faster than 50 fps; APNG keeps exact timing.

Step 1: Count the frames

Most sheets are a grid: one animation per row, frames running left to right. Count the frames across and down. An empty slot at the end of the last row is normal — the animation simply had fewer frames than the row has room for.

You also need the size of the whole image. Your file manager shows it: on a Mac, select the file and choose File → Get Info (look under More Info); on Windows, right-click → Properties → Details.

Step 2: Divide

If the frames touch each other, the arithmetic is one line:

• frame width = image width ÷ columns
• frame height = image height ÷ rows

Example: coin-spin-strip.png is 256 × 32 pixels with 8 frames in one row, so each frame is 256 ÷ 8 = 32 pixels wide and 32 ÷ 1 = 32 pixels high.

When both divisions come out as whole numbers, you are done. A result that is a familiar size — 16, 24, 32, 48, 64, 96 or 128 — is a good sign. A result like 35.5 means something else is in the image.

If you can't tell how many columns there are, work backwards: try the familiar sizes and keep the one that divides both the width and the height exactly and matches the art you see.

When it doesn't divide: margin and spacing

Many sheets leave a border around the whole image (the margin) and a gap between neighboring frames (the spacing). Sprite packers add them on purpose, to keep frames from bleeding into each other when the game scales them. They are invisible on a transparent background, which is why the simple division goes wrong.

This sheet is 142 × 74 pixels, 4 columns by 2 rows. 142 ÷ 4 = 35.5, so it can't be gap-free. With a margin and spacing, the full formula is:

• frame width = (image width − 2 × margin − (columns − 1) × spacing) ÷ columns
• frame height = (image height − 2 × margin − (rows − 1) × spacing) ÷ rows

With a margin of 4 and spacing of 2: (142 − 8 − 6) ÷ 4 = 32, and (74 − 8 − 2) ÷ 2 = 32.

How do you find the margin and spacing if nobody tells you? Counting transparent pixels in an image editor helps, but it can mislead: the art inside a frame rarely touches the frame's edges, so the empty pixels you count are part margin and part frame. Two better clues:

1. Use both directions. Assume the familiar frame size (32 here). The width says 2 × margin + 3 × spacing = 14 pixels; the height says 2 × margin + 1 × spacing = 10. Only margin 4 with spacing 2 fits both. A guess that works for the width but not the height is wrong.
2. Try small values. Packers almost always use 0 to 4 pixels for each. A handful of tries usually finds the pair that makes both formulas come out whole.

Check it by playing the animation

The real test is watching the animation. If the numbers are even slightly off, every frame gets cut at a slightly different spot, and the sprite drifts or jitters while it plays — even though each frame looks almost right on its own.

SpritePilot's Sprite Player does this check for you. Load the sheet and enter the columns and rows; it shows the frame size it worked out and warns you when the grid doesn't use up the whole image:

Set the margin to 4 and the spacing to 2 and the warning disappears: 8 frames, 32 × 32 pixels each, and the coin spins in place. Press Grid overlay to see exactly where each frame is cut on the sheet itself. When it looks right, the Sheet to GIF tool can turn it into a GIF to share.

When it never divides: the sheet is packed

If no margin and spacing make the numbers work, or the frames are clearly different sizes, the sheet isn't a grid. It's a packed atlas: frames placed wherever they fit, often with their empty borders trimmed off. An atlas almost always ships with a data file — JSON, XML or .plist — that lists each frame's rectangle. Look for one next to the PNG; your engine can usually read it directly.

No data file? Split the sheet by its transparent background instead. SpritePilot's Sprite Detection finds each sprite automatically and can export them with the metadata your engine needs. For the step-by-step, see How to Split a Sprite Sheet.

Where the numbers go in your engine

• Unity: select the texture, set Sprite Mode to Multiple, open the Sprite Editor and choose Slice. With Grid By Cell Size, enter the frame size as Pixel Size, the margin as Offset and the spacing as Padding. Grid By Cell Count takes the columns and rows instead.
• Godot 4: in the SpriteFrames panel, use Add frames from a Sprite Sheet. Set Horizontal and Vertical to the columns and rows; for a sheet with gaps, set the frame Size, the Separation (spacing) and the Offset (margin).
• Phaser: pass all four numbers when you load the sheet (frame config reference):

this.load.spritesheet('coin', 'coin-spin-grid.png', {
  frameWidth: 32,
  frameHeight: 32,
  margin: 4,
  spacing: 2,
})

Quick reference

• No gaps: frame size = image size ÷ number of frames across (or down).
• With gaps: frame size = (image size − 2 × margin − (count − 1) × spacing) ÷ count.
• Familiar frame sizes: 16, 24, 32, 48, 64, 96, 128.
• Check by playing it: a sprite that drifts means the margin or spacing is off.
• Frames of different sizes: it's an atlas — find its data file or use automatic detection.

Practice sheets

Both coin sheets from this article are free to use in any project (CC0): the 8 × 1 strip (256 × 32, no gaps) and the 4 × 2 grid (142 × 74, margin 4, spacing 2). Load the grid into the Sprite Player and see if you can make the warning go away. For 70 more animated sprites, all one-row strips named with their frame size and count, see Free Pixel Art Game Assets.

They come from the way the graphics card reads your texture, and they have a handful of well-understood fixes. This article shows what is happening, then goes through the fixes in order — from a one-line settings change to the fix that works for any art style.

What the lines really are

When your game draws a tile, the GPU doesn't copy pixels one to one. For every pixel on screen it works out which spot of the texture that pixel covers and samples the texture there. With smooth filtering (also called linear or bilinear), a sample that falls between texture pixels is a blend of the four nearest ones.

That is harmless in the middle of a tile. At the edge, though, some of those four neighbors belong to the next tile in the sheet. In the picture above, the grass tile sits next to water and above dirt in the tileset, so the grass picks up a thin line of blue on one side and brown on the other. The tileset is fine; the sampling reaches across its tile borders.

You will see it when:

• tiles are drawn at a zoom that isn't a whole number (2.65× here, or any zoom a camera eases through),
• the camera or a tile sits at a fractional position, such as x = 120.5 — smooth camera follow produces these constantly,
• mipmaps are on: the smaller versions of the texture blend whole neighborhoods of pixels, tiles included,
• the texture is compressed: compression works in small blocks that ignore your tile borders.

A related artifact is a hairline gap where the background shows through, when two neighboring tiles' edges round to different screen pixels. The fixes below deal with both.

Fix 1: Nearest-neighbor filtering for pixel art

If your art is pixel art, tell the engine to take the nearest texture pixel instead of blending four. Pixels stay crisp and nothing blends in from the neighbors.

• Unity: select the texture, set Filter Mode to Point (no filter) and Compression to None, then press Apply.
• Godot 4: Project Settings → Rendering → Textures → Canvas Textures → Default Texture Filter → Nearest. Any node can still override it with its own Texture → Filter property.
• Phaser: add pixelArt: true to the game config. Phaser's documentation says it turns antialiasing off and roundPixels on, and calls it "the best setting for pixel-art games".

const config = {
  type: Phaser.AUTO,
  width: 320,
  height: 180,
  pixelArt: true,
  scene: [GameScene],
}

Nearest filtering removes the blending, but on its own it can't stop a sample at a fractional position from landing on the wrong side of a tile edge now and then. That is what the next fix is for.

Fix 2: Keep everything on whole pixels

Most lines appear only at fractional zooms and positions, so the second fix is to avoid them:

• Zoom by whole numbers — 2×, 3×, 4× — rather than 2.5×.
• Round the camera position to whole pixels after smoothing it.
• Unity: add the Pixel Perfect Camera component to your camera and set its Assets Pixels Per Unit to match your sprites.
• Godot 4: Project Settings → Rendering → 2D → Snap → turn on Snap 2D Transforms to Pixel, and Snap 2D Vertices to Pixel if you still see wobble.
• Phaser: roundPixels: true draws sprites at whole-pixel positions (already on with pixelArt: true).

Snapping trades a little smoothness of movement for stable pixels — usually the right trade for pixel art.

Fix 3: Pad and extrude the sheet (works for any art)

Painted or high-resolution art needs smooth filtering, and some games zoom freely. For those, change the sheet instead of the sampling. Two settings do it:

• Padding leaves empty pixels between the sprites, so no two tiles touch.
• Extrusion copies each sprite's edge pixels outward by one or more pixels.

Now a sample that reaches just past a tile's edge lands on a copy of that same edge — the same color — instead of on the neighboring tile.

To make a sheet like this in SpritePilot:

1. Cut your tileset into tiles with Grid Slice, or load your separate tile images. If the tileset has empty cells, untick Skip empty (fully transparent) cells so the tile numbers stay the same.
2. Open Export & Download, set Padding to 2 and Extrude to 1, leave Trim transparency off, and download the sheet with its metadata.

The metadata file (TexturePacker, Phaser, Godot or Aseprite JSON) points at each tile's own 16 × 16 pixels, not at the copied border, so sprites draw exactly as before. The tiles also keep their order, so tile numbers in an existing map still match.

If your engine reads a tileset as a grid instead of a JSON file, give it the sheet's margin and spacing. For a sheet exported this way, margin = extrude and spacing = 2 × extrude + padding. With Extrude 1 and Padding 2 that is margin 1 and spacing 4. In Phaser:

const map = this.make.tilemap({ key: 'level' })
// tileset name in the map, image key, tile width, tile height, margin, spacing
const tiles = map.addTilesetImage('meadow', 'meadow-extruded', 16, 16, 1, 4)
map.createLayer('Ground', tiles)

In Tiled, the same two numbers go in the tileset's Margin and Spacing properties.

The engines also have their own versions of this fix:

• Godot 4 does it for tile maps automatically. A TileSet atlas source has Use Texture Padding, on by default; the documentation says it "generates an internal texture with an additional one pixel padding around each tile" because "texture padding avoids a common artifact where lines appear between tiles". Leave it on. For sprites cut from a sheet with AtlasTexture, the Filter Clip option keeps sampling inside each frame's region.
• Unity's Sprite Atlas has a Padding setting (4 pixels by default) that, in Unity's words, prevents "pixels from one sprite appearing in an adjacent sprite". Packing your tiles into a Sprite Atlas is the usual fix for lines in a Unity tilemap.

Fix 4: Mipmaps and compression

Mipmaps help 3D textures seen from far away; in 2D they mostly blur edges and blend tiles together. Lossy compression does the same in small blocks.

• Unity: in the texture's import settings, untick Generate Mip Maps (under Advanced) and set Compression to None.
• Godot 4: in the Import dock, keep Mipmaps → Generate off and the compression mode on Lossless — the defaults, and what Godot recommends for pixel art.
• Phaser: textures get no mipmaps unless you ask for them in the game config, so there is nothing to change.

If you do need mipmaps — for a 2D game that zooms far out — extrude more than one pixel, because each smaller mip level reaches further across tile borders.

A checklist

For pixel art:

1. Nearest (point) filtering.
2. Whole-number zoom, and the camera snapped to whole pixels.
3. No mipmaps, no lossy compression.
4. Still seeing lines? Pad and extrude the sheet (in Godot, keep Use Texture Padding on).

For smooth or painted art:

1. Pad and extrude the sheet — 2 px padding and 1 px extrusion to start.
2. Mipmaps only if you need them, and then a wider extrusion.
3. Snap the camera if movement shimmers at tile edges.

Try it yourself

The tileset in this article is free to use in any project (CC0): download the tileset (8 tiles, 16 × 16 px) or the padded and extruded version. For animated tiles that repeat seamlessly on every frame, water, lava and a waterfall, see the free Environment Pack.

To pad and extrude your own sheet, open Export & Download — it runs in your browser and nothing is uploaded. For what each metadata format is for, see Sprite Sheet Export Formats Explained.