Splitting a GIF into frames means turning one looping animation file into a stack of still images, one per visible step. The first frame in a GIF becomes frame-01.png, the second becomes frame-02.png, and so on, in the exact order the browser decoder reads them. Each PNG keeps the full logical canvas size of the original animation and shows what a viewer would actually see at that moment, including every previously drawn element still on screen. The decoder does not just copy raw rectangles the encoder stored; it composites those rectangles over the prior canvas using the GIF disposal rules, so a blinking cursor, a moving sticker, or a partial background update becomes a normal, complete PNG that any image editor can open without needing every earlier frame in the chain. The frames are useful for documentation, storyboards, design review, social-media assets, or manual editing, and the work happens inside the browser tab where the file was opened.
Why Splitting GIF Frames Is Harder Than It Looks
A GIF is not a video file with full keyframes. To shrink file size, the GIF encoder often saves a small rectangle that changes after the previous frame instead of a complete canvas on every step. Some of those rectangles include transparent pixels. Some request that their rectangle be cleared after display, while others request that the earlier canvas be restored. If a tool simply pulls out those raw rectangles and saves them as PNGs, every thumbnail except the first will look incomplete, blank, or shifted.
A real frame splitter needs to decode each image block, apply the previous frame's disposal behavior, draw the new patch onto a full logical canvas, and then export that complete canvas as a still image. That extra compositing step is the difference between misleading thumbnails and usable artwork, and it is the reason the GIF Splitter tool is built around a local browser canvas rather than acting as a simple file converter.
How to Split GIF Frames in Your Browser
The whole process happens on the page itself, so the source animation is never uploaded to a remote server. The steps below use the GIF Splitter tool, which decodes the GIF locally and lists every visible frame with its own preview and download link.
- Open the GIF Splitter page and choose an animated GIF from your device. The selected file can be up to 20 MB on disk.
- Select Extract PNG frames. The page runs a local compositing pass, applying each GIF block over the prior canvas using the disposal rules stored in the source file.
- Wait for the numbered previews to appear. Each preview shows the frame number, the full canvas size, and the decoded display delay in milliseconds.
- Review the list and download the numbered PNG files you actually need. Each link points to a real PNG Blob generated from canvas pixels, not a placeholder.
- If your animation is longer than 50 blocks, trim it first or split it externally, then re-run the extraction on the shorter file. The tool caps processing at 50 image blocks per file.
What the Output Files Contain
Each downloaded PNG has the same width and height as the original GIF canvas, with transparency preserved where the source used transparent pixels. The file name follows the source filename plus a zero-padded frame number, which keeps a file manager or image editor listing in animation order. The page also displays contextual metadata that is not embedded in the PNG itself, so you can see the timing before you save.
| Field shown | Source | Written into PNG |
|---|---|---|
| Frame number | Decoded GIF image order, starting at 1 | Yes, as part of the filename |
| Canvas size | Full logical width and height of the GIF | Yes, as PNG pixel dimensions |
| Display delay | Decoded GIF delay in milliseconds | No, shown only on the page |
| Transparent areas | Canvas pixels where alpha was retained | Yes, as PNG alpha channel |
| Raw patch rectangle | The small region the encoder actually stored | No, the full canvas is exported |
Safety Limits and Why Some GIFs Are Rejected
The splitter imposes a small set of hard limits so a tiny-looking file cannot quietly allocate an unreasonable amount of canvas memory. The selected GIF may be at most 20 MB on disk. Its canvas must be at most 4,096 pixels on either side and three million pixels per frame. The page accepts up to 50 image frames and checks both the aggregate patch work and the combined output pixel count before it begins to produce PNG downloads. Animated files often decompress far beyond their original byte size, so these checks run before any output is created. A rejected input produces a clear message and no partial frame list, so you never end up with a half-finished extraction that needs to be cleaned up.
| Limit | Maximum | Why it exists |
|---|---|---|
| Source file size | 20 MB | Stops very large GIFs from blocking the browser tab |
| Canvas width or height | 4,096 px | Keeps a single frame inside typical browser canvas size ceilings |
| Pixels per frame | 3,000,000 | Prevents a single huge frame from exhausting tab memory |
| Image blocks in the file | 50 | Bounds the total work for one extraction run |
After You Have the Frames
Once the PNGs are on disk, they behave like any other still images. You can crop, resize, recolor, watermark, or annotate them individually, then either publish them as separate assets or reassemble a new animation. For step-by-step guidance on rebuilding an animation at a smaller size, the browser walkthrough on resizing a GIF without breaking the animation covers how to put resized stills back together while keeping the visible frames and per-frame timing intact. The extracted PNGs are also a good way to audit a third-party GIF before using it, since you can open frame-01.png, a middle frame, and the final frame to confirm the actual content at three points in the loop without scrubbing through the animation by eye.
How the Local Compositor Works Under the Hood
The compositing pass relies on the browser's canvas and image-data APIs rather than a server-side video tool. When you start the extraction, the page reads the GIF block by block in the order the decoder exposes them, applies the previous frame's disposal instruction at the right moment, draws each transparent patch onto a fresh logical canvas using CanvasRenderingContext2D.putImageData, and turns the final canvas into a downloadable file with HTMLCanvasElement.toBlob. All of that runs inside the current tab, the temporary URLs are revoked when the output is replaced or the component unmounts, and the source GIF itself is never uploaded. If the browser cannot allocate a required canvas or cannot decode the supplied file, the operation stops before any PNG is offered for download, so the page never serves a broken or mislabeled image. The tool also cannot recover frames the browser decoder cannot read, reconstruct a video timeline, preserve GIF comments or application extensions, detect duplicate visual frames, or infer which still is the most useful, so the extracted set is exactly what the source animation contained, nothing more and nothing less.