Sprite Sheet Slicer
Slice a sprite sheet into tiles and download a zip.
Overview
The Sprite Sheet Slicer takes one large sprite sheet and chops it into a grid of individual tile PNGs that you can download as a ZIP. Specify the tile width and height (and optionally a starting offset and gutter), and the tool walks the sheet from top-left to bottom-right, exporting one PNG per cell.
It is the opposite operation to the Sprite Sheet Packer: feed it a sheet from a game engine, an icon library exported as a single image, or a screenshot of a UI component grid, and you get the original tiles back as individual files. Game-modding workflows and frontend teams replacing legacy icon sets reach for it most often.
How it works
Every input cell is the same rectangle (x, y, tile_w, tile_h) where x = offset_x + col * (tile_w + gutter) and y = offset_y + row * (tile_h + gutter). The slicer iterates that grid, allocates a tile-sized pixel buffer for each cell, copies the source rows into it, and encodes the result as a PNG.
The output filenames follow a predictable convention — typically row_col.png or a zero-padded index — so re-importing the tiles into a renderer or a build pipeline is straightforward. Empty tiles (cells where every pixel is fully transparent) can optionally be skipped to keep the ZIP small.
Examples
Input: characters.png (1024x1024, 32x32 tiles, no gutter)
Output: ZIP with 1024 tiles named 00_00.png ... 31_31.png
Input: icons.png (640x128, 64x64 tiles, gutter 0)
Output: 20 PNG tiles named row0_col0.png ... row1_col9.png
Input: ui-mockup.png with 96x96 cells and a 4 px gutter
Output: every cell extracted as a separate PNG, gutter pixels skipped.
FAQ
Does the slicer detect the tile size automatically?
The bundled implementation requires explicit tile dimensions. Auto-detection requires more complex edge analysis and is generally less reliable than supplying known dimensions from the source documentation.
Can it skip empty tiles?
Yes — toggle the "skip transparent" option and any cell whose alpha is fully zero is omitted from the output ZIP.
What about non-uniform tile grids?
This tool handles regular grids. For irregular sprite sheets where every frame has different bounds, you need either a manifest produced by the original packer or a contour-detection step.
Will the output preserve transparency?
Yes — each tile is a PNG with the same alpha channel as the corresponding region of the source sheet.
How are tiles ordered in the ZIP?
By row then column (left-to-right, top-to-bottom). Filenames carry the row and column indices so order-of-extraction doesn't matter for downstream consumers.