Splitting a GIF means decoding one animated GIF file into a numbered sequence of still PNG images, where each PNG shows the complete visible canvas at a specific moment in the animation rather than the small rectangle of pixels the encoder originally stored. Each output keeps the full canvas dimensions of the original animation, not the size of any single changed rectangle, so every PNG opens in any standard image editor the same way a screenshot from the animation would. The output filename carries a padded frame number that matches the decoded image order, so the files stay sorted in the same sequence a viewer sees during playback. PNG is a still format, so the splitter also shows the decoded display delay beside each preview as a reference for reassembly, not as data embedded in the file itself. Browser-based extraction keeps the source file local, nothing is uploaded to a remote queue, and each output PNG exists only in the current tab until you download it or replace the input.
What Splitting a GIF Produces
When a person asks how to split a GIF, they almost always want one or more stills they can use somewhere a video or animation will not play. A documentation page that needs a single representative frame, a slide deck that wants the strongest frame of a reaction, a storyboard that lays every step of a motion out at once, or an editor that wants to touch up one pose before reusing it somewhere else all benefit from the same kind of output: one normal PNG per visible animation frame, at the full canvas size of the original.
The catch is that a GIF file is rarely a stack of complete pictures. Most encoders save a small patch of new pixels per step and tell the decoder what to do with the previous frame before drawing the next one. Some patches include transparent areas, some ask the canvas to be cleared after a delay, and some ask the decoder to restore an earlier canvas. A "split" that exports those raw patches produces a folder of confusing little rectangles that do not look like the animation you started with, and the result is almost never what the user actually wanted.
The fix is GIF Splitter, which decodes the GIF in your browser, walks the frame sequence in order, applies each disposal instruction at the right moment, and composites every patch onto the full logical canvas before exporting that complete canvas as a PNG. The result is one PNG per visible animation frame, ready to drop into documentation, a slide deck, a design review, a social post, or any still-image workflow that needs the exact frame you saw on screen.
Why Raw GIF Patches Are Misleading
A GIF stores animation as a list of image blocks, not as a list of finished pictures. Each block covers a region of the canvas, holds a delay in hundredths of a second, and may carry a "disposal" code that tells the player what to do with that region once the delay has elapsed. The four meaningful disposal behaviors are to leave the region in place, restore the background, restore the previous frame, or take no specific action. Together they let a GIF reuse pixels across frames and stay small on disk.
Exporting the raw blocks instead of the composited result is a common reason people think a GIF splitter is broken. You open one of the saved files and see only a tiny corner, or a transparent rectangle with a blinking cursor, or a frame where the background has been wiped because the decoder never applied the right disposal rule. The animation looked fine in the browser because the browser was painting on a live canvas frame by frame. The exported patch has no idea what was under it.
The composition step is what turns that mess into something useful. By drawing every patch onto a single full-size canvas using the standard canvas pixel-data API and honoring each disposal instruction at the right point in the sequence, the splitter reproduces what a person would actually see during playback. That is also why transparent areas stay transparent in the final PNG: the browser canvas preserves alpha, and the GIF's clear-to-background requests are applied only where the animation asked for them, instead of being filled with an arbitrary background color.
How to Split a GIF With GIF Splitter
- Open GIF Splitter in your browser and pick an animated GIF file from your device. The selected file can be up to 20 MB, and its canvas can be at most 4,096 pixels on either side and three million pixels in one frame.
- Wait for the local validation pass to finish. The page checks both the aggregate patch work and the combined output pixels before it begins compositing, and a rejected input shows a clear message instead of a half-built frame list.
- Click Extract PNG frames and let the local compositing pass complete. Decoding, disposal handling, and PNG creation all happen in your tab; no upload or remote conversion queue is involved.
- Review the numbered previews. Each row shows the frame number starting at one, the canvas size, the decoded delay in milliseconds, and a thumbnail of the full composited canvas at that point in the animation.
- Download the PNGs you need using each row's individual download link. Files are named from the source filename plus a padded frame number, for example animation-frame-01.png, so they stay sorted correctly in any file manager or editor.
- Open the first, a middle, and the final exported PNG to confirm they match the original animation. This visual audit is especially important around transitions that only change part of the canvas, where disposal behavior has the most effect.
Input Limits the Splitter Enforces
The safety limits are deliberate. Animated files can decompress far beyond their original byte size, so a small-looking upload could still ask the browser to allocate an unreasonable number of canvas pixels. The page enforces four hard checks before it begins compositing, and a rejected input produces a clear message rather than a partially committed frame list.
| Limit | Maximum | Why it exists |
|---|---|---|
| Source file size | 20 MB | Keeps the initial decode step responsive. |
| Canvas width or height | 4,096 pixels | Matches typical browser canvas ceilings for image data. |
| Pixels per frame | 3,000,000 | Prevents a single huge patch from exhausting memory. |
| Image frames in the file | 50 | Bounds total compositing work and PNG count per session. |
These four numbers also explain why a perfectly valid-looking sticker animation can still be rejected. The budget is driven by the decompressed pixel work, not the bytes on disk, and a GIF that fits comfortably in a chat window can still ask the browser to allocate far more canvas pixels than the splitter is willing to commit. If a file is rejected, the message identifies the specific limit that was crossed so the source can be trimmed or simplified before another attempt.
Where the Extracted Frames Are Useful
Once each frame is a normal PNG, the stills slot into almost any static-image pipeline.
- Documentation and help articles. Pull a representative still from an animated UI demo to embed in a written guide where a video or GIF would not render.
- Storyboards and design review. Lay every frame in order on a contact sheet to spot timing issues, idle frames, or jumps in a motion sequence.
- Social-media assets. Pick the strongest frame for a static post or cover image without re-encoding the animation.
- Manual editing. Open a single frame in an image editor to fix a detail, then re-import the edited PNG back into an animation tool if you want to rebuild the motion.
- Sticker and reaction creation. Take one expressive frame and turn it into a PNG sticker for chat apps. Once the stills are saved, a browser-based GIF to sticker workflow can carry the rest.
The frame number follows the decoded GIF image order, so the filename padding is more than cosmetic: it is the actual sequence index, and any external tool that consumes the files will read them in the right order without needing a sidecar manifest.
Checking the Frames Match the Animation
For reliable use, open the first, a middle, and the final exported PNG and compare them with the original animation. This is the cheapest way to catch the two cases where a split can quietly go wrong. The first is partial-canvas transitions: a frame where only a small region of the screen changes, such as a blinking cursor or a moving sticker, should still show the full background as a complete PNG. The second is transparency: if a frame contains clear-to-background pixels, those areas should remain transparent in the saved PNG, not filled with black or white, since PNG preserves alpha where the canvas retains alpha.
The splitter also shows the decoded display delay in milliseconds beside each preview. That number is contextual information for sequencing and reassembly, not a guarantee that every player will reproduce the original timing identically. If you rebuild an animation from the extracted stills, treat the delays as a starting point and confirm the result in the destination application.
The tool 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. If the source GIF uses very subtle transparency, color-management differences, or damaged extension data, inspect the resulting PNGs in the destination application before treating them as final.
What to Do After You Split a GIF
Each PNG is created from local canvas pixels and stays available only until you replace the input, leave the page, or close the tab, so save the frames you want to keep before navigating away. Once they are on disk, the rest of the workflow depends on the goal.
If you want a smaller animated result, the stills you just extracted are good source material for re-encoding. A browser-based GIF resize walkthrough can take you from the extracted frames to a tighter animation without uploading anything. If instead you want a single still image in a different format, the PNGs are already lossless and ready for any editor, and a resize or format conversion step is usually a one-click operation in a browser tool.
Use the visible preview list as an audit before deleting or replacing the original GIF. If the row count looks too low, the source may have contained more frames than the browser could decode; if a row looks visually wrong, the source may have relied on extension data the decoder ignored. Both are signals that the input file, not the splitter, needs attention, and the numbered output is the easiest place to confirm that the split captured exactly what the animation showed.