How to Make a Sprite Sheet from Multiple Images
A practical workflow for ordering separate animation frames, placing them into consistent cells, and exporting a clean PNG sprite sheet.
Separate PNG frames are convenient while drawing an animation, but a game pipeline often needs one predictable texture. A sprite sheet maker places those existing images into a regular grid, preserves their order, and exports a single PNG that can be sliced later.
The difficult part is not drawing images onto a canvas. It is deciding which frame comes first, how images of different sizes fit into equal cells, where transparent padding belongs, and whether the final dimensions are safe for the browser and destination engine.
This guide walks through a repeatable way to combine up to 200 existing frames without pretending that a layout tool is an AI sprite generator.
Prepare the frame files first
Collect the frames for one animation or one closely related group. A clean source folder is easier to reason about than a mixed selection containing idle, attack, effects, UI icons, and accidental duplicates.
Before uploading, check these properties:
- Every file represents one intended frame.
- Transparent assets use PNG or another alpha-capable format.
- Frames use the same pixel scale.
- Canvas sizes and pivot assumptions are understood.
- Filenames describe the intended order.
The Sprite Sheet Maker accepts PNG, JPG, WebP, and BMP images, with up to 200 files in one batch. JPG cannot preserve transparency. A JPG frame placed on a transparent sheet still carries its opaque rectangular background.
If the images came from a regular sheet, split them with the Sprite Sheet Cutter first. Exact crops keep a stable cell size and give the rebuilt sheet a better chance of matching the original.
Use filenames that sort naturally
Frame order is animation data even when it is not stored in a separate metadata file. The maker applies natural filename sorting, so names containing numbers follow human expectations: frame 2 appears before frame 10.
For a durable asset library, use descriptive, zero-padded names:
hero-run-001.png
hero-run-002.png
hero-run-003.png
Zero padding is useful because not every tool implements natural sorting. It also makes files align neatly in folders and version-control reviews.
After upload, inspect the list rather than trusting names blindly. A duplicated frame, an exported thumbnail, or a file named “final” can still land in the wrong place. Drag frames to correct exceptions, and remove unwanted files before generating.
Use “clear all” when the selection belongs to a different animation. Building on top of an accidental mixed batch is a common way to create a sheet that looks plausible but plays incorrectly.
Step 1: Choose the number of columns
Columns decide where each row wraps. With 20 frames, 5 columns produce 4 rows; 4 columns produce 5 rows. The reading order remains left to right, then top to bottom.
Choose columns based on both workflow and texture dimensions:
- A horizontal strip is easy to understand for a short animation.
- A near-square sheet avoids extremely long textures.
- A divisor of the frame count fills every row.
- A fixed studio convention makes engine import settings reusable.
The row count is the frame count divided by columns, rounded up. A final row may contain unused transparent cells. Those blank cells are layout space, not animation frames, so do not include them when defining playback.

The default output name includes the calculated grid, such as “sprite-sheet-5x4.png.” Keep that information or replace it with an animation-specific name such as “hero-run-5x4.png.” A meaningful filename reduces the chance of using the wrong slicing values later.
Step 2: Decide how cell size is calculated
A regular sheet requires equal cells even when source images differ. By default, the maker can choose a shared cell large enough to hold the uploaded frames. The source images are placed inside those cells without stretching.
This is useful when visible sprites were exported with slightly different canvases, but it is not a substitute for a deliberate pivot strategy. If one frame is 48×64 and another is 56×64, a shared cell prevents clipping; alignment then determines where each image sits.
Enable a custom cell size when the destination specification is known. For example, a 64×64 project grid may require every frame to occupy a 64×64 cell even when the visible character is smaller. The cell must be at least large enough for the source image after considering the intended placement. A smaller custom cell would clip art and should be corrected before export.
Do not use custom cell size to rescale artwork. It defines the container, not a resize target. If the pixel scale is wrong, use the Pixel Art Upscaler consistently before building the sheet.
Step 3: Pick an alignment rule
Alignment controls the position of each source image within its cell.
| Alignment | Good for | Risk to check |
|---|---|---|
| Center | Icons, effects, evenly centered frames | Feet may move when heights differ |
| Top left | Tiles and coordinate-based exports | Visible subjects may look offset |
| Bottom center | Standing characters with a shared ground line | Tall effects may extend upward |
Bottom-center alignment often works for characters because it keeps the feet near a common baseline. Center alignment is reasonable for explosions or UI icons. Top-left is predictable when source canvases already encode exact offsets.
No automatic rule understands the intended pivot of every animation. Preview the sheet and compare fixed landmarks across frames. If the character jumps even though the motion should be stationary, correct source canvases or choose a more appropriate alignment.
Step 4: Set padding and background
Padding creates space around the outer edge and between cells. Zero padding gives the smallest texture and simplest grid. Nonzero padding can help visual inspection or match a downstream import convention, but it changes every crop coordinate.
When a sheet uses padding, record the exact value with frame width, frame height, columns, and rows. A cutter or engine must know where the first cell begins and how far to advance.
Choose a transparent background for ordinary sprites. A solid color is useful when that color is an intentional part of the texture or when exporting assets for a system without alpha. It does not remove backgrounds from source frames: an opaque white rectangle in a JPG remains white even on a transparent canvas.
For filtered texture atlases, transparent padding alone may not prevent color bleeding. Production packers often extrude edge pixels into a border. The maker creates a regular layout, not edge extrusion or mipmap-safe packing, so review engine sampling settings.
Step 5: Check the predicted output before generating
The final dimensions depend on columns, rows, cell size, and padding. A simple mental model is:
width = columns × cell width + padding around and between columns
height = rows × cell height + padding around and between rows
Increasing cell size affects every frame; increasing columns can reduce height while increasing width. Review the predicted dimensions before allocating the canvas.
If either dimension exceeds 8,192 pixels, the interface shows the expected size and memory warning and asks whether to continue. This is a chance to make an informed decision. Split unrelated animations, reduce padding, choose a more balanced column count, or correct oversized source canvases when possible.
The compressed PNG file may be small while decoded texture memory is large. One 8,192×8,192 RGBA buffer is roughly 256 MiB before extra processing buffers and engine copies. A theoretical maximum is not a recommended target for every platform.
Step 6: Generate, preview, and export
Generate the sheet and inspect it at both fit-to-screen and pixel zoom. Verify:
- Frame order crosses row boundaries correctly.
- No source image is clipped.
- Alignment keeps intended pivots stable.
- Transparent areas remain transparent.
- Cell size and padding match the displayed plan.
- The last row contains only expected frames.
Download the PNG only after those checks. Keep the list of source files and settings until the sheet runs correctly in the destination. The PNG does not embed columns, rows, frame rate, animation names, or pivots.
If the preview is wrong, fix the inputs and regenerate rather than editing the combined image blindly. Changes made directly on the sheet are harder to trace back to source frames.
Import the sheet into a game engine
Set the engine to the exact cell width and height. If padding is zero, a regular grid slice is straightforward. With padding, specify the offset and gap values where supported; otherwise prepare a zero-padding version for import.
For pixel art, use nearest or point filtering and avoid compression that introduces new edge colors. Confirm the pivot for several different-sized frames, especially after bottom-center or center placement.
Build animation clips using only real frames. When the final row is incomplete, the geometric grid may contain more cells than the uploaded file count. Do not let transparent unused cells become pauses unless that is intentional.
Common problems
Frame 10 appears before frame 2
The downstream tool is sorting text rather than numbers. Rename files with zero-padded indexes and rebuild, or explicitly preserve the maker's sequence metadata in your own workflow.
Small frames move around inside the animation
Source canvases differ and the selected alignment does not represent the intended pivot. Use bottom-center for a stable ground line, standardize source canvases, or configure engine pivots.
One image is clipped
The custom cell is smaller than that source frame or alignment pushes content beyond the cell. Increase the cell dimensions and regenerate.
Transparent output still has white boxes
Those boxes are pixels in the source images, often from JPG or precomposited PNG files. Remove the source backgrounds before combining.
The output is unexpectedly huge
Inspect unusually large source canvases, custom cell size, columns, and padding. One accidental high-resolution frame can enlarge every cell.
A maintainable workflow
Keep source frames as the editable master and treat the sheet as a generated artifact. Use consistent names, one animation group per batch, documented grid settings, and a known pivot convention. Regenerate the sheet whenever a source frame changes.
For other transformations, the game asset tools hub links the cutter, GIF converter, pixel-art converter, and upscaler. Keeping each step explicit makes errors easier to identify and undo.
Make a sprite sheet from your imagesFAQ
Does the maker generate new animation frames with AI?
No. It arranges images you upload. It does not invent art, poses, or transitions.
Can source frames have different dimensions?
Yes. They can share an automatically selected or custom cell, with alignment controlling placement. Check pivots carefully.
Which image format should I use?
Use PNG for transparent game sprites. JPG works for opaque images but cannot carry alpha and may add compression artifacts.
How many images can I combine?
The current batch limit is 200 source images, subject to output dimension and browser-memory checks.
Does the PNG store animation speed or grid metadata?
No. Record frame rate, columns, rows, cell size, padding, and pivots separately for the engine import.