Convert, Split, and Repack a Sprite Sheet: A Worked Example

You can turn an animated GIF into a sprite sheet, recover its individual frames, and repack them into a different layout without changing the frame pixels. The key is to keep the frame size, order, and spacing explicit at every step. This walkthrough uses four numbered frames so you can check the result yourself.

Start with the sample GIF, convert it into a 128 × 128 grid, split it into four 64 × 64 PNGs, then pack those PNGs into a 256 × 64 strip. Each stage has a downloadable reference. You can also start from the grid or the separate frames if you only need part of the workflow.

Download the sample files

• Input animation: four-frame GIF — 64 × 64 pixels, 10 FPS, 0.4 seconds.
• Reference grid: PNG and Generic JSON frame data — four cells in a 2 × 2 layout.
• Individual frames: ZIP — four numbered PNGs. Extract the ZIP before adding them to the atlas tool.
• Reference strip: PNG and Generic JSON frame data — the same four cells in one row.

These original geometric sample assets are free to use and modify, including commercially, without attribution. The sample notes include the reproduction settings and permissions.

1. Convert the GIF into a grid sheet

Open Video & GIF to Sprite Sheet and select the sample animation. In the extraction step, choose 10 FPS, 100% scale, and 4 maximum frames. Leave the optional maximum frame size empty. Extract the frames, keeping all four in their original order.

The sample gives every frame a 100 ms delay. Sampling at 10 FPS matches that timing: 1,000 ms ÷ 10 = 100 ms per frame. This is a deliberately uniform animation; the example does not test preserving arbitrary variable delays from other GIFs.

In the layout step, use these settings:

• Layout: Grid.
• Columns and rows: 2 columns, 2 rows.
• Direction: Left → Right.
• Padding: 0 px.
• Maximum sheet size: 256 × 256.

Generate and download the PNG. It should be 128 × 128 pixels, not 256 × 256: the maximum sheet size is a limit, while these four frames only need two 64-pixel cells in each direction.

Select Generic JSON when exporting the frame data. The four rectangles should start at (0, 0), (64, 0), (0, 64), and (64, 64). Each rectangle is 64 pixels wide and 64 pixels high. Your filenames may differ from the reference; compare the coordinates and dimensions.

2. Split the sheet back into PNG frames

Open Sprite Sheet Splitter and select your exported grid, or use the reference grid PNG. Set 2 columns and 2 rows. Under the advanced settings, leave both offsets and both spacing/margin values at 0. Override any automatic grid suggestion.

For this sheet, the calculation is straightforward: 128 ÷ 2 gives a 64-pixel frame width and height. Split the sheet, then check that the previews show 1, 2, 3, and 4 in that order. Download the ZIP.

You should receive four 64 × 64 PNGs. The output prefix controls their names, so different names do not indicate a pixel mismatch. What matters here is the image content, dimensions, and order.

This splitter expects a uniform grid. A tightly packed atlas can place differently sized or rotated sprites at irregular positions; dividing such an atlas into equal cells would cut through sprites. Keep its metadata for a loader or extractor that understands those coordinates.

3. Repack the frames into a strip atlas

Extract the ZIP and add its four PNGs to Images to Atlas in numerical order. You can also use the separate reference frames. Choose Grid (Uniform) and a maximum size of 256.

Set scale to 100%, padding to 0, and extrusion to 0. Turn transparent trimming and duplicate detection off, and leave power-of-two sizing on. These settings keep this exercise focused on rearranging complete cells.

Generate the atlas. Four 64-pixel cells fit across the 256-pixel width, producing one 256 × 64 PNG. All frames now start at y = 0; their x coordinates are 0, 64, 128, and 192.

Download new metadata with the new atlas. The grid's old coordinates no longer describe this image: frame 3 moved from (0, 64) to (128, 0). A texture and its coordinate file belong together.

What we checked

For this walkthrough, we ran the supplied files through the three tools in desktop Microsoft Edge. The GIF conversion produced the reference 128 × 128 sheet, the splitter recovered four reference frames, and the atlas tool produced the reference 256 × 64 strip. We compared decoded PNG pixels, rather than expecting identical compressed file bytes.

The sample generator also checks that the GIF contains four 100 ms frames and that cropping the reference sheets recovers the original pixels. The reference JSON comes from the application's Generic JSON exporter. These checks cover this small sample; they are not a benchmark for large clips or a certification of every browser, codec, or game-engine importer.

If your result differs

• More or fewer frames: check the 10 FPS extraction rate and the maximum of 4 frames.
• Unexpected sheet dimensions: check scale, padding, layout, and whether you accepted different recommended settings.
• Wrong extraction order: use left-to-right ordering for the grid and add the separate images to the packer in numerical order.
• Sprites clipped by the splitter: verify the 2 × 2 grid, zero offsets, and zero spacing. This sample has no outer sheet margin.
• GIF extraction is slow to start: the video tool downloads its FFmpeg processing core on demand. The initial load needs a network connection even though conversion runs locally.

Apply the workflow to your own artwork

Once the sample works, replace it with your animation and change one setting at a time. Zero padding makes this example easy to inspect; it is not a universal production setting. The pixel-art padding guide explains the next decisions to make for texture filtering.

For mixed-size images, explore the atlas packer's other layouts and retain the resulting metadata. Use the Texture Atlas Calculator to compare texture dimensions and memory estimates. For engine import, choose a format your loader actually supports; a Generic JSON file describes the frames but is not a universal automatic importer.

Your source media is processed in the browser rather than uploaded for conversion. Site analytics and optional forms use network requests. Keep a copy of your original files and settings so the same workflow is easy to repeat when the artwork changes.