GIF Splitter extracts every visible frame of an animated GIF as a fully composited PNG inside your browser tab, so you can hand someone a sequence of stills from an animation without uploading the source file. The page reads the GIF locally, applies the previous frame's disposal instruction at the correct point, and draws each transparent patch onto the full logical canvas before exporting that complete canvas as a numbered PNG Blob. Each download link points to a real PNG built from canvas pixels, not a stored rectangle and not a server-generated file. Frame numbers follow the decoded GIF image order starting at one, the displayed delay is the decoded display delay in milliseconds, and the PNG keeps the full logical canvas dimensions so transparent areas stay transparent. A rejected input yields a clear message and no partially committed frame list, and every temporary URL is revoked when the output is replaced, the component unmounts, or you close the tab. That combination makes the page useful when you want to break a short animation into a series of stills for documentation, a design review, social posts, or a manual storyboard, which is exactly what "gift Split Fiction moments" tends to mean in practice for an animated GIF.

What Gifting a Split Fiction GIF Really Involves
If you came here looking to share an animated GIF clip, whether it captures a Split Fiction moment or any other animation, the underlying task is to split that GIF into separate, fully composited stills. The page covers exactly that workflow: a small animation loaded into your tab, a list of numbered previews, and a row of real PNG downloads built on the spot. The actual splitting comes down to three short actions in GIF Splitter, and the rest of this article walks through what each step produces and why the output looks the way it does.
The technical part of that workflow is what makes the tool worth using over a generic converter. A short reaction GIF, a co-op match clip, or a UI animation can be passed around easily as a single file, but breaking it into separate stills for a comment thread, a blog post, a slide deck, or a chat with a friend usually loses the moment you actually wanted. Some tools hand back the raw change rectangles stored inside the GIF, which produces cropped, half-empty PNGs that misrepresent the frame as it appeared on screen. The page covered here does not.
Why Raw GIF Patches Are Not the Same as Visible Frames
The animated GIF format is older than most modern image containers and stores frames in an unusual way. Instead of saving a complete canvas for every step, a GIF encoder often stores a small rectangle that only changes after the previous frame. The encoder can also flag the new rectangle as transparent, ask that its region be cleared after display, or request that the previous canvas be restored before the next frame is drawn. Some blocks include transparent pixels inside the changed region, and some do not.
Exporting those raw rectangles would create misleading thumbnails and incomplete PNG files. A blinking cursor, a moving sticker, or a partial background update would become a tiny cropped square rather than the full frame a person actually saw. GIF Splitter avoids that problem by composing each stored block over the current logical canvas, applying the prior disposal instruction at the right point, and exporting the resulting full visible canvas. The browser canvas is used for the actual PNG creation, which is why the implementation can rely on standard canvas APIs rather than a hand-rolled rasterizer. The two relevant primitives are documented at MDN's putImageData reference and MDN's HTMLCanvasElement.toBlob reference, which are the canvas methods the page leans on most heavily.
| Stored inside the GIF | What you actually see on screen | What the splitter exports |
|---|---|---|
| A small rectangle that updates after the prior frame | A complete canvas with all earlier content intact | The full visible canvas after compositing |
| A rectangle flagged as transparent | Pixels that reveal the underlying canvas | Transparent PNG pixels where the canvas stayed transparent |
| A rectangle requesting "restore to previous" | The canvas as it looked two frames earlier | The restored full canvas, exported as one PNG |
| A rectangle requesting "clear after display" | A blank area where the new content sat | The blank area rendered into the full PNG |
Split a GIF into PNG Frames Locally
The actual extraction is short, and the page guides you through it.
- Choose an animated GIF up to 20 MB. Pick the file from your device; the page reads it locally without sending a network request. Files outside the 20 MB limit, with canvas dimensions above the supported range, or with more than 50 image frames are rejected before any PNG is created.
- Select Extract PNG frames and wait for the local compositing pass to finish. The page decodes each stored block, applies the previous frame's disposal instruction, and draws the resulting canvas before it produces any PNG Blob. Nothing leaves your tab during this step.
- Review the numbered previews and download the full PNG frames you need. Each preview shows its frame number, the canvas size, and the decoded display delay in milliseconds. Click the download link beside the frame you want, and the browser saves a numbered PNG named from the source filename plus a padded frame number, such as animation-frame-01.png.
The padded number is deliberate: file managers and image editors sort the PNGs in the same order as the original animation, so you do not have to rename anything before you share or upload them. Download the frames you need, then use the output list as a visual audit before deleting or replacing the original GIF.
What Each Output PNG Carries
Three pieces of reference data travel with every preview, and they are also baked into any workflow you can build on top of it:
- Frame number. The frame number follows the decoded GIF image order, beginning at one. It is not a guess at the most useful still or a smart-pick summary; it is the literal position in the decoded sequence.
- Canvas size. The PNG preserves the full logical canvas dimensions. The tool does not crop each frame down to the changed rectangle or resize the image, so what you see in the preview matches what you will get in the file.
- Decoded delay. The shown delay is the decoded display delay in milliseconds. It is contextual information for sequencing the stills, not a promise that every player or platform will display the original timing identically.
Because PNG supports alpha, transparent areas in a composited GIF frame stay transparent where the browser canvas retains transparency. If you need a smaller output image or a new animated GIF, the recommended path is to check the extracted frames first and then move to GIF Resizer for size changes or GIF Optimizer for palette work, rather than reaching for those tools first.
Limits That Decide Whether the Split Completes
The safety limits on the page are not arbitrary; animated files can decompress far beyond their original byte size, and a small-looking upload can otherwise force the tab to allocate an unreasonable number of canvas pixels. The published bounds are:
| Limit | Value | Why it matters |
|---|---|---|
| Source file size | Up to 20 MB | Bounds the initial read and decode work in the browser tab. |
| Canvas dimensions | At most 4,096 pixels on either side | Keeps a single frame inside the canvas size the browser can allocate reliably. |
| Pixel count per frame | Up to 3,000,000 pixels | Prevents a large canvas from multiplying the total compositing work. |
| Frame count | Up to 50 image frames | Limits the total number of PNG downloads the page will produce. |
Both the aggregate patch work and the combined output pixels are checked before the page begins to create PNG downloads. A rejected input yields a clear message and no partially committed frame list, so you never end up with a half-finished row of previews that you have to clean up before re-trying.
Verify the Frames Before You Gift or Share
Open the first, a middle, and the final exported PNG after extraction and compare them against the original animation. Pay special attention to transitions that only change part of the canvas, because that is where a mis-disposed patch would show up as a stray rectangle in the PNG. If the GIF uses very subtle transparency, color-management differences, or damaged extension data, the resulting PNGs should be inspected in the destination application rather than trusted blindly.
Two checks are worth running for any GIF you plan to hand off. First, confirm that the previews match the original animation at the moments you actually wanted to capture, especially around any partial background update. Second, confirm that the PNGs sort in the right order when you open them in a file manager or editor; the padded frame number keeps that ordering reliable, but only if the source filename is consistent across the batch.
What the Tool Does Not Do
The implementation is deliberately narrow, and that is part of why it stays reliable. The page 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 for your specific task. It also does not upload the source or keep a permanent copy of the extracted images. The tool does not combine frames into a contact sheet, add filename labels, draw a background behind transparency, or re-encode a new animation.
If you need those features, the cleanest path is to start from the extracted PNGs and pass them to a more specialized tool. Image Resizer can shrink the stills, Photo Collage Maker can arrange them into a contact sheet, and GIF Maker can rebuild a new animation from a chosen subset of frames.