Extract the frames from an animated GIF and pack them into a PNG sprite sheet. Strip or grid, transparent gutters, a JSON sidecar with the frame timing, and a ZIP of the frames on their own.
Every frame is decoded and fully composed in your browser, so GIFs that only store the changed region per frame come out complete. Nothing is uploaded.
Horizontal strip, vertical strip, or a grid with as many columns as you like. Add transparent padding between frames if your engine samples with filtering, and drop repeated frames to keep the sheet small.
The sheet as a PNG, the frames as individual PNGs in a ZIP, and a JSON sidecar with each frame's rectangle and duration so an importer can rebuild the animation with the original timing.
A sprite sheet is only useful if the thing reading it knows where the frames are. For a strip that is easy: every frame is the same size, so the engine divides the width by the frame count. That is why horizontal is the default here and the layout most engines and tools expect, including the sprite-sheet inputs on this site.
Grids exist because textures have limits. A 60-frame GIF at 128 px wide makes a 7680 px strip, which some engines refuse or downscale. Packing it 8 wide keeps the sheet inside a 1024 px texture. Whichever layout you pick, the JSON sidecar records the exact x, y, width and height of each frame plus its duration in milliseconds, in the same shape most pixel-art editors export. Importers that read that format, and there are plugins for most engines, can take the sheet and the JSON together and play the animation back with the timing the GIF had. If you only need the pictures, the ZIP of frames is there too.
Yes. The GIF is decoded in your browser and never uploaded. No account, no watermark, no limit on how many you convert.
Horizontal strips are the most common input for game engines and for tools like ours that expect one row of frames. Use a grid when the GIF has a lot of frames, because many engines cap texture width at 4096 or 8192 pixels. Vertical is there for engines and shaders that read frames top to bottom.
Yes. Transparent pixels in the GIF stay transparent in the PNG, and any padding you add between frames is transparent too. Frames are fully composed first, so GIFs that only store the changed region per frame come out complete.
One entry per frame with its filename, its x, y, width and height on the sheet, and its duration in milliseconds taken from the GIF's own timing. It follows the JSON shape most pixel-art editors export, so engine importers that read that format can use it directly.
Some GIFs repeat identical frames to hold a pose. That option merges each run of identical consecutive frames into one and adds their durations together, so the animation timing in the sidecar is unchanged but the sheet is smaller.
The reverse: play a PNG sheet back as an animated GIF at any frame rate.
Split any sheet into frames by grid or auto-detect, with a ZIP download.
Snap any image to 2 to 64 colours, with optional dithering.
Open SpriteLab to keep building with your sprites.