GIF to PNG

Drop a GIF here and get PNG back in this tab. A GIF is a container of frames, each with its own palette, delay and disposal rule; a PNG is one still picture. This page reads the container first — how many frames it holds, how many are stored as small patches, how large each palette is, whether it loops — then decodes the frames in your browser. Take frame 1 as a single PNG, pick another frame, or turn every frame into a numbered PNG sequence in a ZIP. Nothing is uploaded.

Drop GIF files here

or choose files · up to 20 at a time · 60 MB each · 500 frames per file · still or animated

GIF in, PNG out · one frame or every frame · up to 20 files, 60 MB each, 500 frames per file · no upload · no account · no watermark

GIF to PNG: One Frame or Every Frame, and Where the Bytes Go

A GIF is a stack of frames; a PNG is one picture. That sentence decides the whole conversion. Keep one frame and the PNG is a fraction of the GIF's size: 3,650 bytes from a 13,236-byte file on the 24-frame test below. Keep every frame and the same GIF becomes 24 PNGs totalling 87,577 bytes, 6.6 times the original. The pixels are identical either way. What changes is how much of the file you ask for.

A GIF is a container, a PNG is a page

The 24-frame test file opens with a logical screen of 480 × 270, a global palette of 4 entries, and then 24 image blocks. Twenty-three of those blocks are smaller than the canvas: the encoder stored only the rectangle that changed. Across all 24 frames the file holds 336,494 stored pixels, against 24 × 129,600 = 3,110,400 pixels if every frame were painted in full.

A PNG has no frame table. One file is one picture at one size, and every pixel of that picture is written. So the conversion starts by asking the decoder to compose the frame you want: patches placed at their offsets, colours looked up in the local palette, disposal rules applied. Only then does a canvas exist that a PNG can hold.

That is why the page reports the frame count before it reports a size. A still GIF with one image block and an animation with 60 frames are the same conversion in name only.

What one frame costs, and what all of them cost

Four animated files, converted both ways on this page:

File	Canvas	Frames	GIF	Frame 1 as PNG	Every frame as PNG	Every ÷ GIF
anim-square.gif	480 × 270	24	13,236 B	3,650 B	87,577 B	6.62×
anim-transparent.gif	200 × 200	12	4,465 B	2,142 B	25,556 B	5.72×
loop3.gif	240 × 160	8	3,279 B	1,455 B	11,643 B	3.55×
anim-long.gif	320 × 180	60	16,856 B	2,170 B	131,306 B	7.79×

Both columns are true. One PNG from the 60-frame file is 12.9% of the GIF's size, because the GIF is carrying 59 frames you did not ask for. Every PNG from the same file is 7.8 times the GIF, because each of the 60 files is a full 320 × 180 canvas. Neither number is a bug, and neither is the one to quote without saying which question it answers.

Why the sequence grows: the GIF only stores what moved

Take that 480 × 270 animation apart. In the GIF, the average stored frame covers 14,020 pixels, 10.8% of the canvas. The other three files land at 19.4%, 24.5% and 5.7%. The encoder leaned on the fact that most of the picture had not changed.

PNG has no equivalent. The format stores pixels, not deltas between files. Every PNG in the sequence carries all 129,600 pixels, and the encoder cannot know that frame 17 differs from frame 16 in a 60-pixel corner.

The file sizes show it. The 24 PNGs from anim-square range from 3,627 to 3,655 bytes, a spread of 28 bytes, even though the GIF's stored rectangles vary from a few hundred pixels to most of the canvas. A whole-canvas picture costs about the same no matter how little changed since the last one: in this sequence, 3,649 bytes on average, against 551 bytes per frame inside the GIF.

The ZIP that carries the sequence adds its own overhead. On anim-square, 24 PNGs of 87,577 bytes became a 90,623-byte archive, 3.5% more. On the 60-frame file the archive was 138,648 bytes against 131,306, 5.6% more. A ZIP of PNGs cannot shrink them further in any useful way; it only packs them into one download.

"Frame 2" is a patch, not a picture

GIF frames arrive with a disposal rule. Disposal 0 and 1 both leave the frame on the canvas; 2 clears the area back to the background before the next frame. The three fixtures happen to cover all three: loop3 uses 0 on all eight frames, anim-square uses 1 on all 24, anim-transparent uses 2 on all 12.

Reading the tenth image block of anim-square would give you a rectangle, possibly a few hundred pixels wide, with a local palette and transparent gaps. That is not frame 10 of the animation. The page decodes through the compositor, so frame 10 comes back as a 480 × 270 picture — the same picture a viewer sees at that point in the loop.

The check was boring and total: all 104 PNGs from the four animations were compared with a separate GIF decoder's composited output, pixel by pixel in RGBA. All 104 matched with zero differing pixels, including every disposal rule and every transparent index. The single-frame outputs matched on every visible pixel as well; the only difference anywhere sat in the RGB bytes under fully transparent pixels, which no viewer shows.

What survives, and what a PNG has no room for

Transparency survives exactly. The logo fixture is 320 × 320 with 41,668 transparent pixels, 40.7% of the canvas; the PNG keeps those pixels transparent, and its alpha channel holds two values, 0 and 255. The transparent animation is 90.1% transparent on its first frame, and still carries two alpha values. GIF cannot store partial transparency, so nothing here invents a soft edge.

Colour survives without dithering. The photo fixture holds 252 colours; the PNG holds the same 252. The flat one holds 6—same count after conversion. A GIF's 256-entry ceiling travels into the PNG unchanged: the new container can hold millions of colours, but it only receives the ones the GIF had.

Four things do not travel:

• The loop count. loop3.gif records 3. The page reads it and prints it on the card; a PNG has no field for it.
• The frame delays. anim-long stores 4/100 s on every frame, anim-square 8/100 s, loop3 12/100 s. A sequence of PNGs keeps the pictures and loses the timing.
• The comment block. comment.gif carries the text "free tool, local conversion" in a 238-byte file. The page reads the comment and shows it; the PNG writer emits no text chunk.
• Interlacing. An interlaced GIF stores its rows in four passes. The decoded picture is the same, but the PNG is written top to bottom: every output here has interlace byte 0 in its header.

The PNG container on this page is three chunk types — IHDR, one or more IDAT, IEND — with no PLTE (the output is 8-bit RGBA), no tEXt, no sRGB and no gAMA. Whatever a still PNG could carry in theory, this writer carries pixels only.

When a PNG is smaller than the GIF

Six single-frame files at their own size:

File	Canvas	Palette entries	GIF	PNG	Change
flat.gif	400 × 300	8	2,558 B	4,141 B	+61.9%
logo.gif	320 × 320	4	2,010 B	5,584 B	+177.9%
interlaced.gif	400 × 300	16	1,844 B	3,946 B	+114.0%
tiny.gif	64 × 64	4	326 B	308 B	−5.5%
photo.gif	600 × 400	256	51,029 B	58,933 B	+15.5%
comment.gif	120 × 90	4	238 B	507 B	+113.0%

The logo is the clearest case against PNG on size: 40% of its canvas is empty, and the PNG still writes four bytes for every pixel before compression. The photographic frame pays a milder 15.5%, because its palette was already near the 256-colour ceiling.

tiny.gif is the exception that proves the rule. At 64 × 64 and four colours, PNG's zlib stream beats GIF's LZW stream by 18 bytes, 5.5%. A lossless format with a better compressor wins when the picture is small enough that the compressor, not the pixel count, sets the bill. On anything larger, the palette is the cheaper way to say the same thing.

How to convert a GIF to PNG here

1. Drop the GIF. Up to 20 files at once, 60 MB each, 500 frames per file.
2. Pick what to keep. "One frame — one PNG" uses the frame number in the box; "Every frame — PNG sequence" writes one file per frame with zero-padded names.
3. Download. A single frame saves as one PNG. A sequence saves as a ZIP built in the tab, with the files named name-frame-001.png through name-frame-060.png.

There is no run button: changing the mode or the frame number recomputes the preview and the size on the card.

What the controls do

The Output menu chooses between one frame and the whole sequence; in one-frame mode the number box takes 1 to the file's frame count, clamped per file when several GIFs are loaded. The card reports the canvas size, the input bytes, the output bytes and, for an animation, which frame you are looking at. The page reads the GIF header before decoding — version, canvas, frame count, how many frames are stored as patches, local palettes, transparency, interlacing, loop count and delay — because those are the facts that decide what the conversion can and cannot keep. The batch limit is 20 files, 60 MB each and 500 frames per file; all-frame mode also stops a batch whose decoded pixels would exceed 150 million.

Why this page doesn't upload your GIF

The GIF parser, the browser's frame decoder, the canvas and the PNG writer all run in the tab. A server would add a copy, a queue and a download without making a single pixel different.

Two checks are open to you. Open DevTools (F12), switch to Network, then convert a file: no request carries the image. The harder test is to load this page, disconnect the network and convert anyway. The 24-frame sequence went through with the connection off and came back byte-identical: SHA-256 b9042c8eec72e8e9cb1cdd174c9b9c6bd2858aae133684590ea24b178d807c2b online and offline.

Before you delete the GIF

• Check the frame count on the card. If it is above 1, you are about to replace an animation with stills.
• Decide whether you need one frame or all of them; the size difference between the two answers is 3× to 8× on the files measured here.
• If the PNG is larger and size is the point, keep the GIF or resize the picture first. The format change alone will not make it smaller.
• If the GIF loops or has a deliberate frame rate, keep the original: those values stop at the PNG.
• Confirm the transparency against a dark background. GIF transparency is on/off, and a PNG made from it will be on/off too.

Questions that come up

Does converting a GIF to PNG keep the animation? No. A PNG holds one picture. This page can write every frame as a numbered PNG sequence, but playing them in order needs a format with timing — GIF, APNG, WebP or video. The delays are read from the GIF and shown on the card; they are not written into the PNGs.

Can I extract every frame at once? Yes. Choose "Every frame — PNG sequence" and the page writes one PNG per frame, then packs them into a ZIP in the tab. The test clips here ran from 8 to 60 frames; the page accepts up to 500 frames per file, 60 MB per file and 20 files per batch.

Why is my PNG sequence bigger than the GIF? Because the GIF stored only the parts that changed, and PNG stores a full canvas every time. On the 24-frame 480 × 270 test, the GIF's frames cover 10.8% of the canvas on average; the 24 PNGs total 87,577 bytes against 13,236. One frame alone is 3,650 bytes, smaller than the GIF.

Is transparency preserved exactly? Yes, at the level GIF can express it. GIF transparency is one palette index, so every pixel is either fully transparent or fully opaque. The PNG here carries two alpha values, 0 and 255: a 320 × 320 logo with 41,668 transparent pixels kept all of them, and no new soft edges appeared.

Which frame is "frame 1"? The first frame a viewer sees, after the GIF's disposal rules have been applied — not the first image block in the file. On files with patches, that block can be a small rectangle. The page composites before writing, so every PNG is the full canvas.

What happens to the loop count and frame delays? They are read from the GIF and reported on the card, then dropped. A PNG has no timing fields: the output chunk list is IHDR, IDAT and IEND. If the timing matters, keep the GIF or rebuild the animation in a format that stores it.

Why did a tiny GIF come out smaller as PNG? PNG's compressor can beat GIF's on very small, very flat pictures. A 64 × 64, four-colour GIF went from 326 to 308 bytes, 5.5% smaller. Above that size the palette wins: a 400 × 300, eight-colour GIF grew 61.9%, and a 320 × 320 logo grew 177.9%.