There is no single correct sprite frame size. A 16 × 16 icon, a 32 × 32 character, and a 256 × 128 painted effect can all be valid. The useful question is not “What size should every sprite be?” but “What cell can contain every pose while keeping the animation aligned at its intended display scale?”
That distinction matters because a frame has at least three sizes:
Those measurements may be different. A character can occupy only 24 × 29 visible pixels inside a 32 × 32 frame, then appear much larger on screen because the game scales the sprite or camera.
Choose frame dimensions from the visual job the asset must do.
First decide how large the character or effect should look beside the rest of the game. Then identify the widest and tallest pose in the animation. A sword swing, squash frame, dust cloud, or hair movement may need more room than the idle pose.
Add only enough transparent room to contain those extremes and keep the intended anchor stable. Excess empty canvas wastes texture space; too little canvas clips motion or forces one frame to use a different size.
Common dimensions such as 16, 32, 48, or 64 pixels can be convenient for art direction, but they are conventions rather than requirements. Powers of two are not required for each individual frame. Your engine and target platform determine any limits that matter for the final texture.
Consistent width and height make a regular sprite sheet easy to slice. Consistent alignment makes it look stable.
Pick a logical anchor—often the point where a character's feet meet the ground, the center of a projectile, or the attachment point of an effect. Place that point at the same pixel coordinate on every frame canvas. The visible artwork can move around the anchor; the anchor itself should not drift accidentally.
This is why cropping every pose tightly is often a mistake. Tight crops create different canvases and move the subject relative to the frame origin. The animation may wobble even when the drawing is correct.
Sprite Sheet Tool can accept mixed-size images. Its packer uses the largest source width and height as the cell, then centers smaller frames inside that cell. That is useful for a quick layout, but centering is not the same as preserving a foot, hand, or effect pivot. If exact alignment matters, normalize the source canvases in your art editor before packing them.
For a gapless grid, the dimensions are straightforward:
sheet width = cell width × columns
sheet height = cell height × rows
rows = ceil(frame count ÷ columns)
For example, twelve 32 × 48 frames in four columns produce three rows and a 128 × 144 sheet when spacing and outer padding are both zero.
If you add spacing S between cells and outer padding P, use:
sheet width = (2 × P) + (cell width × columns) + (S × (columns - 1))
sheet height = (2 × P) + (cell height × rows) + (S × (rows - 1))
Write down the cell size, columns, rows, spacing, and padding. Those values are part of the asset contract with the importer. Guessing them later is a common cause of partial or combined frames.
The free sprite sheet editor can pack your prepared PNG, JPG, or WebP frames, show the output dimensions, and preview the sequence before export. Derive the cell size from your normalized source canvases and keep it with the asset notes. For the full packing workflow, follow how to make a sprite sheet from images.
If you inherited a sheet, divide its usable width and height by the expected columns and rows. Subtract known margins and gaps first. A remainder usually means one of four things: the row or column count is wrong, the sheet includes padding, frames are not actually uniform, or the image was rescaled after export.
Use the sprite sheet splitter to test a row-and-column grid or an exact cell size. Preview the extracted sequence. A correct-looking first cell is not enough; inspect the outer cells and the final row, where bad measurements often become obvious.
A fixed cell is not mandatory for every rendering pipeline. A tightly packed texture atlas can store a different rectangle for each sprite, provided the runtime reads matching metadata and preserves the sprite's logical pivot separately. Large effects may also deserve their own atlas instead of forcing every character frame into an oversized cell.
Even in those cases, animation alignment still needs an explicit rule. Variable rectangles save texture area; they do not automatically solve pivots, timing, or scale.
Sprite Sheet Tool does not trim artwork, detect feet, or choose pivots for you. It arranges the pixels and reports their rectangles. Do the semantic alignment in the source art or engine, then use the preview to catch mistakes before the sheet becomes a dependency for animations and code.

Understand outer padding, gaps, edge extrusion, and sampler settings so you can diagnose texture bleeding without breaking sprite sheet slicing.

Plan sprite animation FPS, loop duration, and per-frame holds with simple timing math, then carry those choices into your game engine.