Step 1
Choose maker or slicer
Maker mode starts from separate PNG, WebP, JPEG, or other browser-readable image files. Slicer mode starts from one existing sheet with a regular row-and-column grid.
The upload controls, canvas preview, grid settings, PNG or GIF encoder, metadata, and download actions hydrate in the browser. Large files stay on this device: nothing leaves your browser.
Make a sheet · slice a sheet · private in-browser workflow
Build a sprite sheet from multiple images, or switch to the slicer to cut an existing grid into individual PNG frames and download them together as a ZIP. All pixel work stays on your device.
Step 1
Maker mode starts from separate PNG, WebP, JPEG, or other browser-readable image files. Slicer mode starts from one existing sheet with a regular row-and-column grid.
Step 2
For making, choose columns, padding, and gaps; the largest source dimensions define the cell. For slicing, enter the exact columns and rows so the sheet divides into equal frame rectangles.
Step 3
Maker mode downloads one PNG and exposes its layout metadata. Slicer mode encodes every cut frame as PNG, adds metadata.json, and creates a single client-side JSZip download.
A reliable sprite sheet is a geometry contract. The renderer and the importer must agree on cell size, row order, padding, and gaps.
Maker mode uses the widest uploaded image as frame width and the tallest as frame height. Smaller images are centered without smoothing or rescaling, so their original pixels remain unchanged.
Files are placed in upload order from left to right, then top to bottom. Rename or select files in the intended animation order before exporting when filename sorting matters.
Slicer mode divides sheet width by columns and sheet height by rows. Both divisions must be exact integers; otherwise a one-pixel remainder would shift later frames or silently drop edge pixels.
The cutter does not trim transparent borders because trimming changes every frame's origin. Fixed-size frames are usually safer for animation alignment and collision data.
Each frame is encoded as an RGBA PNG. JSZip then stores numbered files such as frame-001.png and a metadata.json file describing columns, rows, dimensions, and frame count.
ZIP compression reduces repeated PNG and JSON bytes, but PNG data is already compressed, so archive savings vary. The archive is assembled in memory and never sent to a server.
Four real 4×4 RGBA fixture images arranged in 2 columns produce an 8×8 sheet with no gap or padding. When the same fixture uses 1-pixel padding and gaps, the result is 11×11 and the PNG is 132 bytes.
Slicing the 8×8 fixture back into a 2×2 grid returns four 4×4 PNG frames. JSZip packages those frames plus metadata.json into an 893-byte archive; frame-001.png is 80 bytes in that tested archive.
Open Maker mode, upload the images in frame order, choose a column count, and download the PNG. The largest image defines the common cell size and smaller frames are centered.
Yes. Switch to Slicer mode, upload the existing sheet, and enter its columns and rows. The tool cuts equal frames and packages numbered PNGs in a ZIP.
No. Image decoding, canvas drawing, PNG encoding, slicing, and JSZip generation all run locally. Nothing leaves your browser.
It uses the order provided by the file picker or drop operation, then fills the grid left to right and top to bottom. Check the on-page frame list before export.
Equal integer cells prevent partial pixels and cumulative offsets. If the dimensions do not divide evenly, verify whether the original sheet includes an outer margin or gaps between frames.
No. Every frame keeps the same dimensions and origin. That consistency prevents visible jitter when frames are played as an animation.
The archive contains frame-001.png through the last frame plus metadata.json with the grid and frame dimensions. JSZip creates the archive entirely in browser memory.