GIF Maker: Turning a Set of Still Images into One Animated GIF

By Renan · Sao Paulo, Brazil

A GIF maker takes a sequence of still pictures and writes them into a single file that plays by itself. That sentence hides most of the decisions that decide whether the result looks like an animation or like a slideshow nobody wanted, and it hides one hard constraint: the browser has to hold every frame in memory while it works. This article walks through what happens between dropping the files and downloading the finished GIF, which settings actually change the outcome, and where the format still wins in 2026.

What a GIF maker does with your images

The pipeline is short. Each file you add is decoded into a bitmap, scaled to the output width, painted onto a common canvas and turned into a palette-limited frame. The frames are then handed to an encoder that writes the GIF89a structure around them: a header, a global or per-frame colour table, the frame data compressed with LZW, and a small application extension that tells the viewer how many times to repeat the loop.

Two details of that structure explain most of the practical behaviour. First, every frame carries its own palette of at most 256 colours, so a smooth photographic gradient has to be approximated by nearest neighbours, and the encoder may spend time dithering to hide the steps. Second, the compression is applied inside each frame. A video codec looks at the previous frame and stores only what changed; GIF cannot, so a hundred frames cost roughly a hundred pictures.

Everything the tool does before the encoder starts is a chance to reduce what those hundred pictures cost. That is why frame order, output width, colour quality and the frame delay matter more than any other setting on the page, and why the tool shows you the byte size of the finished file instead of quietly handing over a twenty-megabyte surprise.

Why GIF still earns its place in 2026

The format is old enough to have been standardised before the web existed, and the arguments against it have been correct for a decade. Animated WebP is typically about 64 percent smaller for the same content, and animated AVIF goes further still. MP4 shrinks the same animation by roughly an order of magnitude with better colour and real inter-frame compression. Guidance from the web performance community is blunt about it: if you control the page markup, use a muted looping video element and forget the GIF.

What keeps GIF alive is not the format, it is everything around it. Email is the clearest case. Mail clients block or strip video far more reliably than they block images, and support for animated WebP is uneven, so a GIF remains the only animation that renders in every client that renders images at all. The same logic applies to chat apps, forum uploads, ticketing systems and any workflow where a file has to be accepted by software you do not control.

There is a second reason, less discussed but easy to feel: a GIF autoplays without controls. No play button, no progress bar, no volume icon, no negotiation with the autoplay policy. It behaves like an image that happens to move, which is exactly what a reaction in a group chat or a loading state in a bug report needs. The price is bandwidth, and the fix is to keep the animation short.

One accessibility note belongs here. Motion that starts by itself and lasts more than a few seconds can be a problem for readers who are distracted or sensitive to movement, and the WCAG guidance on pause, stop and hide asks for a way to stop it. A loop that runs two or three seconds and then repeats is far easier to live with than a ten-second recording, and a GIF that plays once and stops is easier still.

Frame delay: the setting that decides how it feels

The delay sets how long one frame stays on screen before the next is drawn. It is normally written in milliseconds, and its reciprocal is the frame rate: 200 ms is five frames per second. Getting this number wrong is the difference between an animation that looks deliberate and one that looks broken, and the ranges below have settled into a rough consensus across the tools people use every day.

Two hard limits sit under the table. Viewers do not honour delays that are too short: several tools warn that browsers ignore values below about 20 ms and silently play the animation at their own minimum, which is why a very fast setting can look slower than a moderate one. And a long delay on a short sequence is not animation at all, it is a slideshow with no controls.

The default in this GIF maker is 200 ms, printed next to the equivalent frame rate so the number is never ambiguous: the page shows 200 ms and 5.0 fps for the same setting. For a photo sequence that is a reasonable starting point. For anything that should look like motion rather than a sequence of stills, cut the delay to 70 or 80 ms and watch how much of the smoothness comes back.

The delay applies to the whole sequence here. Tools that offer per-frame timing exist, and they are useful when one step of a tutorial needs to be read while the rest should move quickly, but a single global value covers most real work and is much easier to reason about while you are still deciding what the animation should do.

Order, loops and the boomerang pass

The order of the frame list is the order of the animation, and every GIF maker exposes the same three ways to fix it: move a frame left or right, remove a frame that breaks the flow, or reverse the entire sequence. Numbered filenames help, because a set exported from a design tool usually arrives in the right order already, while a folder of photos does not.

Looping is a single switch. Turned on, the file carries a repeat count of zero, which every viewer reads as forever. Turned off, the count is one and the animation plays through and freezes on its last frame, which is the behaviour you want for instructions, for a before-and-after comparison, or for any animation that sits next to text a reader is trying to read.

The boomerang option is the one worth understanding before you dismiss it. It appends the frames in reverse after the forward pass, so a five-frame sequence becomes a ten-frame loop that returns to its starting point. Without it, a forward-only loop jumps from the last frame straight back to the first, and that jump is visible whenever the two frames differ noticeably. With it, a rotating product or a toggle interaction reads as a continuous motion. The cost is honest and predictable: twice the frames, so a file roughly twice the size, which is why boomerang suits short sequences and not long ones.

Output width, colour quality and where the bytes go

Two controls decide the size of the file more than anything else, and neither of them is the quality slider people reach for first.

The output width is the first. The tool takes the aspect ratio of the first frame, scales every frame down to the width you choose, and never scales anything up, so a small source stays sharp instead of turning into mush. The arithmetic is worth internalising: cutting both dimensions in half removes three quarters of the pixels, and the compressed size falls roughly in step. Going from an 800 by 600 output to 400 by 300 does more for the file size than any palette trick.

The quality slider is the second, and it works backwards from what the name suggests. It maps onto the encoder's own scale, where the lowest value spends the most time searching for a good palette and the highest finishes fastest with the coarsest approximation. The default of 10 sits in the middle and suits most photo sequences; push it toward 1 when a gradient has to stay smooth and toward 20 when the frames are flat screenshots and the palette hardly matters.

The background colour matters in one specific case. Frames that carry transparency have to be flattened before they can be drawn onto a common canvas, and the tool paints them over the colour you pick, white by default. If you are assembling logos or interface screenshots, set the background to the colour the GIF will sit on, or the edges will carry a halo of the wrong shade.

Finally, the number of frames is the multiplier on everything above. GIF costs roughly one compressed image per frame, so a sequence of forty screenshots will never be small, no matter how the sliders are set. The community rule of thumb for anything meant to be shared is to aim for two to three seconds of loop, use about five frames per second for slideshow-style steps, eight to twelve for interface demos, and reserve higher rates for motion that genuinely needs them.

Which image files a browser can actually decode

A GIF maker that runs in the browser is limited by what the browser can turn into pixels. The safe core is the set every engine has supported for years: PNG, JPEG, WebP, GIF and BMP, plus SVG through the browser's own renderer. Everything else needs a decoder shipped with the tool, and that is where makers differ.

This one covers nineteen formats: PNG, JPG, WebP, GIF, BMP, AVIF, JXL, HEIC, SVG, ICO, TIFF, TGA, PSD, QOI, HDR, EXR, XBM, DDS and camera RAW. The point of that list is not variety for its own sake. A frame sequence often starts life as something that was never meant to be a web image: a PSD export from a designer, a DDS texture, a DNG straight off a camera, a HEIC photo from a phone. Converting each of those to PNG first is an extra step and an extra generation of quality loss, and the decoders here are loaded on demand, so a heavy RAW decoder costs nothing until a RAW frame is actually in the list.

Two practical limits apply. Each image can be up to 50 MB, which is generous for a still and is checked before the file is read rather than after. And the browser holds the decoded frames, the canvas and the encoder's working memory at the same time, so the practical ceiling is the memory of the device rather than a number in the interface. Sequences of a few hundred ordinary images are comfortable on a desktop; a hundred frames of camera RAW on an older phone is not, and the honest answer there is to set a smaller output width.

GIF against WebP, AVIF and MP4

The comparison that decides most projects is not which format is technically better, it is which format the receiving system will accept. The numbers below come from vendor and community benchmarks rather than from a single controlled test, and they move with content, but the order of magnitude is stable.

The practical reading is this: if the animation is part of a page you build, put an MP4 behind a muted, looping, inline video element and stop worrying about the file size. If the animation is a file that has to survive being attached, pasted or uploaded somewhere you do not control, export a GIF. The interesting middle case is a forum or content system that accepts WebP, where the smaller file is worth taking because the format is usually also served to modern browsers without a fallback. Note, too, that some large platforms quietly convert what you upload: a few social networks accept a GIF and serve an MP4 of it instead, which means the format you export is not always the format the audience receives.

Making a GIF in four steps

1. Add at least two images. Drop them onto the page or browse for them; each file becomes a frame and anything above the per-image limit is refused immediately rather than after a long decode.
2. Put the sequence in order. Move frames left and right until the first frame is the one that should set the aspect ratio, then delete whatever breaks the flow.
3. Set the four numbers. A frame delay of 70 to 100 ms for motion and 200 to 300 ms for a slideshow, an output width that halves the largest source rather than matching it, a quality of 10 unless the frames are photographic, and a background colour if the sources carry transparency.
4. Create the GIF and read the size. The encoder runs off the main thread with a progress bar, and the finished file reports its real byte count before you download it, which is the moment to go back and cut the width if the number is larger than the place you are sending it to.

Renan

Sao Paulo, Brazil · SO reputation 2000 · Badges: 4🥇24🥈38🥉 · SO member since 2010