Convert PNG to GIF and build the animation frame by frame

Turning PNG to GIF is an assembly job, and assembly has an order

Nobody sets out to make a worse picture. People arrive here holding a handful of exported stills — screenshots of a five-step process, renders from a 3D program, panels of a comic, a chart at four points in time — and they need those stills to advance on their own, in one file, somewhere that will not accept a video. That is the job, and it is a different job from anything a converter usually does, because a converter takes one thing and returns one thing while this takes several and has to be told how they relate.

The relation is sequence. Which comes first, what follows it, how long each one stays. Those answers are not in the files, they are in your head, and a tool that guesses them from filenames will be wrong the day your exporter names things render_9 and render_10. So the sequence is a list you control, not a result you receive.

Order is the decision nobody plans for

Dropped files arrive in whatever order the browser reports, which for a multi-select is usually alphabetical and occasionally is not — and alphabetical is a numbering scheme only when every number has the same width. Ten files named one through ten come back with ten wedged between one and two, and if the tool just accepts that, the animation stutters backwards in the middle and you spend a while assuming the export was broken.

Every row therefore carries move-up, move-down and remove as ordinary buttons. Not drag handles: buttons work with a thumb, with a keyboard and with a screen reader, and they stay precise when the list is taller than the screen — which happens at about eight rows on a phone, well before anyone considers their sequence long. Above the list, a strip of numbered thumbnails shows the order that will actually be written, so the two can never disagree about what is about to happen.

What 256 colors costs, counted before it runs

Painting a GIF frame means choosing 256 survivors and reassigning everything else to whichever of them sits nearest. Exported stills rarely cooperate: a single screenshot with a window shadow in it can hold tens of thousands of separate shades. On flat artwork — interface captures, logos, diagrams, line drawings — the reassignment is frequently undetectable, and cutting to 64 survivors stays undetectable while taking a serious bite out of the result. Put a sky or a soft gradient through it and the seams appear at once.

So the count is taken from your own files and printed beside the palette setting while you can still change it, instead of being explained later to somebody who already downloaded a disappointment. Dithering swaps those seams for fine grain, which the eye forgives and the compressor does not, so it buys quality with bytes; both figures land on the receipt, and trying it costs nothing because re-running never re-reads a file. Opacity narrows the same way. Wholly invisible pixels stay invisible, but there is no vocabulary in the format for halfway — a drop shadow or a smoothed curve arrives as a hard outline, and that is flagged the moment such pixels are spotted rather than left for the result to communicate.

PNG and GIF, in brief

PNG

Full name	Portable Network Graphics
Extension	.png
Format type	Lossless raster image, with alpha
MIME type	image/png

GIF

Full name	Graphics Interchange Format
Extension	.gif
Format type	Lossless raster image, 256 colors, animatable
MIME type	image/gif

Two hundredths of a second is the floor, and here is why

Durations here are counted in hundredths, which sounds like ample resolution until the second rule turns up: a stored 1 gets played everywhere as if it read 10. That convention is thirty years old, a vast quantity of files on the web now lean on it, and no browser vendor intends to be the one who breaks them. The practical floor is therefore two units, and anything claiming more than fifty pictures a second is claiming something the container cannot record.

Type a figure under twenty milliseconds and the panel tells you, in advance, that twenty is what gets stored and that the sequence will run longer than the number you entered. Leftover fractions travel along the sequence rather than being discarded at each frame, which sounds pedantic and is not: resolve them individually and a few hundred frames end up finishing a good part of a second late.

One canvas for every frame

A GIF declares its dimensions once, at the top of the file, and every frame lives inside them. A folder of exports rarely cooperates — someone cropped one, someone else grabbed a window at a different zoom — so something has to give, and there are only three ways to give. Enlarging the small ones invents detail that was never captured. Cropping the large ones discards content without asking. Scaling down proportionally and centering does neither, so that is what happens here.

The canvas comes from whichever image is first in your order, which makes it a decision rather than an accident: move a different file to the top and the canvas follows. The dimensions and the number of images affected by them are shown before conversion. Afterwards the receipt counts how many frames were stored as nothing more than the rectangle that differed from the one before, which is where a smaller animated GIF comes from and why a sequence on a fixed background compresses so much better than one where everything moves. If it still needs to weigh less after that, there is a separate page for aiming a finished GIF at a specific number of kilobytes, which is a different problem from building one and gets its own set of levers.

What this does not attempt

There is no timeline, no per-frame delay, no easing, no text, no transitions and no reverse. One delay covers the sequence, which is the right shape for stills captured at an even pace and the wrong shape for a hold on the final panel — if you need that, duplicate the last image a couple of times, which is exactly how it was done before anyone had a timeline. Frames are never invented between your images.

Your files stay in the tab. They are decoded by the browser you are already using, composited onto the shared canvas, reduced to a palette by median-cut and packed with the compression the format has used since 1987 — all on a background thread and none of it over a network, so there is no queue to wait in and no upload to finish first. And if what you have is a moving file rather than a stack of stills, a video or an existing GIF taken back apart are the doors marked for that.