The GIF Splitter tool turns one animated GIF into separate, fully composited PNG frames that you can download individually, with each frame's number, canvas size, and decoded delay shown in the browser tab. It runs on the page you are reading: the file is decoded by the browser, the tool applies the correct disposal instructions from the prior frame, draws each block onto a logical canvas, and turns that canvas into a real PNG Blob. Unlike exporting raw GIF patch rectangles — which only cover the area that changed since the previous frame and often include transparent pixels that depend on earlier playback — every PNG the tool produces represents the full visible canvas at that point in the animation, so it opens as a normal still image in any editor. The split happens entirely on your device, with no upload, account, or remote conversion queue. You receive a numbered list of real PNGs named from the source filename plus a padded frame number — animation-frame-01.png, animation-frame-02.png, and so on — and each link points to a PNG Blob you can save or feed into a different workflow.
What lives inside a "gift card" GIF file
The phrase "gift card" usually means a prepaid payment card, but the way it is often typed into a search box — "how to split gift card" — is a common slip-of-the-thumb for "GIF." People who type that phrase are almost always trying to break a short animated GIF into individual still images. It helps to know what the file actually contains, because an animated GIF is not a stack of finished pictures waiting to be renamed.
The encoder often writes a small rectangle that updates part of the canvas plus an instruction telling the player what to do with the previous frame's leftovers: leave them alone, clear them out, or restore the canvas to whatever it looked like two frames ago. That compact approach keeps file sizes small, but it also means the bytes inside a GIF cannot be saved as PNGs directly without producing fragments that show only a piece of the screen.
A naïve "extract" step that reads each image block and renames it as a PNG therefore yields misleading thumbnails. A frame showing a blinking cursor might look like a tiny dotted square; a partial background update might show a colored patch against transparency. Neither file looks like the still image the user actually saw during playback. Some blocks include transparent pixels, others request that their rectangle be cleared after display, and still others request that the earlier canvas be restored. Exporting those raw rectangles would create incomplete PNG files that confuse anyone who opens them later.
The disposal methods are what make a raw export useless without context. "Leave in place" says the new patch sits on top of whatever was there before. "Restore to background" rolls the canvas back to whatever it looked like before the previous frame was drawn, which can wipe out elements that were intended to persist. "Restore to previous" rolls it back to an even earlier state. Without tracking those instructions, any extracted PNG would either look right by accident or look visibly wrong.
The splitter handles this compositing for you. For every image block, the page tracks the previous disposal behavior, draws the new patch over the running logical canvas, and exports that complete view as the PNG. A blinking cursor, a moving sticker, and a partial background update each become a normal full PNG that opens in any editor without needing the earlier frames for context.
How to split a "gift card" GIF into PNG frames
The GIF Splitter tool is built around five short steps that take place entirely in the current browser tab.
- Choose an animated GIF up to 20 MB from your device using the file picker.
- Select "Extract PNG frames" and wait while the local compositing pass completes. There is no remote server in this loop, so the time it takes depends on the file's frame count and canvas size, not your upload speed.
- Review the numbered previews the page produces. Each preview shows the full visible canvas, the frame number, the canvas size, and the decoded display delay.
- Download the full PNG frames you need by clicking the individual download link on each preview. Each link points to a real PNG Blob named with a padded frame number such as animation-frame-01.png.
- When you have saved what you need, replace the input GIF or close the tab to clear the temporary previews and revoke their download URLs.
Through the entire workflow the source file never leaves your device. The page reads it from your local file picker, decodes it inside the browser, and hands you back individual PNG files. There is no server upload, no remote conversion queue, and no account.
What the page shows for every extracted frame
Each preview that appears after extraction includes four pieces of information, pulled straight from the decoded file and the current canvas.
| Field | Meaning |
|---|---|
| Frame number | Position in the decoded GIF image-block order, beginning at one. |
| Decoded delay | The GIF display delay in milliseconds, shown as reference for sequencing stills back into an animation. |
| Canvas size | The full logical width and height in pixels. |
| Download link | A real PNG Blob, not a placeholder, named with a padded frame number. |
The PNGs preserve the full logical canvas dimensions and keep transparent areas transparent where the browser canvas keeps transparency. PNG supports alpha, so a frame with partial transparency stays openable in editors without flattening. The page does not crop each frame down to the changed rectangle, resize the image, combine frames into a contact sheet, add a filename label behind the picture, or re-encode a new animation. If you want one smaller output image, run the extracted frames through a resizing tool after auditing them; if you want a single new GIF, an optimization tool can re-encode the originals.
Input limits and the reason they exist
The tool enforces deliberate safety limits so an animation cannot quietly push the browser tab past a reasonable allocation.
| Limit | Allowed value |
|---|---|
| File size of the selected GIF | Up to 20 MB |
| Canvas width or height | Up to 4,096 pixels |
| Pixels in a single frame | Up to 3,000,000 |
| Image blocks (frames) per file | Up to 50 |
Animated files can decompress far beyond their original byte size, so these checks look at both the aggregate patch work and the combined output pixels before any PNG is created. A rejected input returns a clear message, and no partial frame list is committed to the page. If the current browser cannot allocate a required canvas or cannot decode the supplied GIF, the operation stops rather than serving a broken or mislabeled file.
These caps protect the tab from hanging on a small-looking GIF that would actually allocate an unreasonable number of canvas pixels, and they keep the compositing step responsive. Exactly which limit gets hit depends on the file: a short looping sticker that is well under 20 MB on disk might still have a frame larger than the three-million-pixel cap, while a long reaction GIF that looks small in bytes can push past 50 image blocks once the encoder has been generous with disposal changes.
Auditing the PNGs after extraction
For reliable use, open the first, a middle, and the final exported PNG after extraction. Compare them with the original animation, especially around transitions that only change part of the canvas. If a GIF uses very subtle transparency, color-management differences, or damaged extension data, inspect the resulting PNGs in the destination application before deleting the source.
If a frame in the middle of the sequence looks transparent where it should be solid, open the original GIF again and compare the playback at that exact moment; subtle transparency, color-management differences, or damaged extension data can all produce visible mismatches. If a frame looks correct in the page preview but appears wrong after you save it, the issue is more likely in your destination application than in the export: very subtle alpha channels, color profiles, or extended metadata can confuse image editors that expect standard sRGB PNGs.
The PNG files do not carry animation timing. The decoded delay is shown on the page for sequencing, but it is contextual information, not a guarantee that every player or platform will display the original timing identically. Use the output list as a visual audit before deleting or replacing the original GIF. Padded filenames keep a file manager or editor in the same order as the animation: animation-frame-01.png comes before animation-frame-02.png without manual sorting. If you need to rebuild the stills into a single animated GIF with new timings, run the extracted PNGs through the right downstream tool after confirming the frames you saved are the ones you actually wanted.
Privacy and local processing
The splitter does not upload your source file and does not keep a permanent copy of the extracted images. Decoding, compositing, PNG creation, previews, and downloads happen locally in the browser, and temporary object URLs are revoked when output is replaced, when the component unmounts, or when you close the tab. Each output is available only until you replace the input, leave the page, or close the tab.
The implementation relies on the browser canvas for actual PNG creation and uses local GIF decoding only after you start the extraction. This keeps the page's initial code small and means there is no network request for your file. If the browser cannot allocate a required canvas or cannot decode the supplied GIF, the operation stops rather than serving a broken or mislabeled file.
For readers who want to inspect the canvas primitives the tool depends on, the MDN reference pages for CanvasRenderingContext2D.putImageData and HTMLCanvasElement.toBlob describe how pixel buffers are written to a canvas and how a canvas is exported as a PNG Blob.
For a deeper look, see Optimize Animated GIFs for Faster Web Pages.
For a deeper look, see How to Split Images for Your Instagram Grid in Order.