Sprite Sheet Slicer

Choose the slicing method that matches the sheet

A sprite sheet can be a precise matrix of animation frames, a tileset with regular padding, or a loosely packed collection of icons. Those layouts need different forms of detection. The slicer keeps them in one workflow while leaving the final decision with you.

These controls follow established sprite workflows rather than inventing a new grid model. Unity’s Sprite Editor supports automatic slicing as well as grids by cell size or cell count, with offset, padding, empty-rectangle, and pivot choices. Aseprite’s sprite-sheet importer similarly uses an x/y offset, sprite width and height, padding, and sheet order. This slicer focuses on extraction, so it exports crop coordinates but does not claim to create Unity, Godot, or Aseprite project files.

Auto-detection is a starting point, not a promise

Auto-detection looks for disconnected visible regions. It is quick when sprites have transparent space between them, but no detector can infer every artist’s intended frame boundaries. Two touching characters may appear to be one component; a detached shadow or sparkle may appear as another. Phaser’s extraction guide documents the same connected-pixel limitation: touching sprites are detected together.

Always review the numbered boxes before export. Auto-detection has no tolerance, minimum-size, or merge-distance sliders, so refine the result by hand. If a flat background is being read as artwork, set empty-pixel detection to the corner background color, or turn detection off and slice by grid instead. If the result is too fragmented, delete the stray boxes and draw one box around the whole sprite. If two frames touch, replace the merged suggestion with manual boxes. The original sheet is never changed.

What the ZIP and frames.json contain

PNG is the default output because it preserves exact pixels and transparency. Each selected frame receives a safe, unique filename based on its name or the chosen prefix. The ZIP groups those PNGs with a frames.json manifest. A manifest entry records the frame’s name, order, and source rectangle:

{
  "name": "player-run-03",
  "x": 128,
  "y": 64,
  "width": 32,
  "height": 48
}

Coordinates use the source image’s pixels, measured from its top-left corner. They are useful for scripts and custom pipelines, but the file is deliberately generic, not an engine-native atlas or import file.

Private local processing with bounded recovery

Image decoding, detection, editing, cropping, and ZIP creation happen in your browser. The image bytes and filenames are not sent to the server. To make the multi-step workflow recoverable, the active tab can keep a bounded local working copy and settings for up to two hours. Start over removes the active tab’s project immediately. A separately opened tab has its own isolated copy, which is automatically removed within two hours even if another tab is reset.

For large sheets, close other image-heavy tabs and avoid creating hundreds of empty frames. The slicer reports its size or frame limit instead of silently lowering image quality. Downloads use temporary browser object URLs, which are released after use in line with MDN’s object URL guidance.

Review checklist before export

• Confirm the reading order matches the animation or tile sequence.
• Zoom in and check the first, middle, and last frames for one-pixel drift.
• Exclude empty cells and accidental dust unless their positions are meaningful.
• Use distinct names and check for duplicates before creating the ZIP.
• Check transparent edges on a contrasting preview background.
• Correct boxes with fields or buttons when precision dragging is difficult; the workflow is designed to remain keyboard-operable, following W3C keyboard guidance.