A flip-book, priced like one
A GIF is not a video. It is a stack of complete still images with a delay written beside each one, and each of those images is stored as an 8-bit palette index and compressed with LZW — a dictionary coder from 1984 that is excellent at long runs of identical pixels and nearly useless on photographic noise. There is no motion estimation, no reference frame, nothing that notices two frames are almost the same picture.
That single fact governs everything on this page. We encoded real photographs through this exact encoder and measured0.56 to 0.75 bytes per pixel per frame; flat colour bands came out at 0.033 and an interface screenshot at 0.006. Two orders of magnitude between a photograph and a screenshot, and no amount of setting-fiddling crosses that gap. Twelve frames of a photograph at 800 pixels wide is about five megabytes, which is a surprise worth having before the download rather than after it.
So the estimate sits under the Build button and in the Result panel, it is driven by a sample of your actual pixels rather than a constant, and past 3 MB it turns red and says why in words. Halving the width quarters the file — that is usually the fix, and it is a better fix than dropping to 32 colours.
The delay you asked for and the delay you get
The frame delay is an unsigned 16-bit count of hundredths of a second, so the finest step available is 10 ms and every value you type is rounded onto that grid. A request for 33 ms — a tidy 30 frames a second — is stored as 30 ms. That much is just the format being old.
The part that catches people is underneath it. Every major browser engine replaces a delay of 0 or 1 hundredth with 10 hundredths, a rule inherited from Netscape in the 1990s to stop pages full of zero-delay GIFs from pinning the processor. It is not configurable, it is not reported, and it is why a GIF exported at "100 fps" plays at ten. This tool models the rule: the preview waits the delay a browser will really honour, and says so when your setting is about to be overridden. A preview that plays at a speed the file cannot achieve is the most convincing kind of lie a tool can tell.
One palette, shared by every frame
A GIF frame can address at most 256 colours. The format allows each frame to carry its own colour table, and quantising frame by frame is the obvious implementation — it is also wrong twice over. It writes up to 768 extra bytes into every frame, and because each table is derived from different pixels, flat areas shift hue slightly from frame to frame. The result is that faint boiling shimmer you have seen on badly made GIFs.
Here the palette is built once, from every frame you dropped, and shared. Reducing the colour count shrinks the file and makes banding more visible in gradients; dithering trades that banding for a fine speckle, which looks better and usually encodeslarger, because scattered error gives LZW fewer runs to collapse. Both controls are on the page with that trade-off written next to them rather than hidden behind a single "quality" slider that means nothing in particular.
What it will not do, and why
No video input here. Turning an MP4 into a GIF the portable way means ffmpeg compiled to WebAssembly. That build is GPL-2.0, so shipping it to your browser is distribution and would drag this entire site under the same licence, and it is around 9.7 MB even gzipped. So video is a separate tool, video to GIF, which decodes with the browser’s own WebCodecs instead, in the browsers that have them.
No soft transparency. GIF has one fully-transparent palette slot and no partial alpha at all. A PNG with a feathered edge cannot survive that — it would come back as a hard, ragged fringe — so transparency is flattened onto a background colour you choose, and the choice is visible rather than assumed to be white.
No enormous canvases. A browser canvas caps out around 8192 pixels a side, and older iOS additionally caps the total near 16 megapixels. Past either limit a canvas does not raise an error; it returns a blank image, and you would get a perfectly valid animation of an empty rectangle. Anything over the ceiling is scaled to fit and the tool tells you the number it used.
Before you make one: should it be a GIF?
This is the tool's own advice against itself, and it is the most useful paragraph here. The same animation as an MP4 or WebM is commonly ten to fifty times smaller and plays more smoothly, because modern video codecs store only what changed between frames and are not stuck at 256 colours. If you are putting the result on a web page you control, use a muted autoplaying video and everybody's data plan is better for it.
GIF is the right answer when the destination will not accept anything else — a chat client, a forum, a wiki, an old email template, a README on a code host, a slide deck that only takes images. That is a real and common situation, which is why this exists. It is just not the default.
If what you actually needed was a smaller still image, the image compressordoes that losslessly for PNG; if you needed to crop or straighten the frames first, the image editordoes it without a round trip through a lossy format. Both, and the rest, are on the converterspage.
Questions people ask
Straight answers. Each one links directly: copy the address after opening it.
Why is my GIF so enormous?
Because GIF has no inter-frame compression worth the name. Every frame is stored as its own 8-bit indexed image and squeezed with LZW, a 1980s dictionary coder that does brilliantly on flat colour and almost nothing on photographic detail. Measured with this encoder: a photograph costs about 0.6 bytes per pixel per frame, so twelve frames at 800 pixels wide is roughly five megabytes. A flat graphic costs about 0.03 — twenty times less. That is why the size is shown before you press the button rather than discovered in your downloads folder.
What frame delays can I actually use?
Multiples of 10 milliseconds, because the format stores the delay as a count of hundredths of a second. Ask for 33 ms and the file will say 30. There is a second, nastier rule underneath it: every major browser silently replaces a delay of 10 ms or less with 100 ms, a rule inherited from Netscape to stop early web pages pinning the CPU. So a "100 fps" GIF plays at 10 fps everywhere, with nothing reporting the substitution. The preview here runs at the delay a browser will really honour, so what you see is what the file does.
Can I feed it a video?
Not this one: it takes images, as the market leader’s own GIF Maker does. Video to GIF is its own tool on this site, and it decodes the clip with the browser’s WebCodecs. The portable alternative, ffmpeg compiled to WebAssembly, is GPL-2.0 (shipping it would oblige this whole site to become GPL) and roughly 9.7 MB even gzipped, so it is not used.
Why only 256 colours?
That is the whole format. A GIF frame indexes into a palette of at most 256 entries, and one of those is usually spent on transparency. This tool builds a single palette from every frame you dropped, which is what stops colours shifting between frames — quantising each frame on its own is the easy mistake, and it writes up to 768 extra bytes into every frame while making the animation flicker. Choosing fewer colours makes the file smaller and the banding more obvious; dithering hides the banding by scattering the error, and usually makes the file bigger because it gives LZW less to work with.
What does the loop count actually do?
Zero means forever, and that is written into a Netscape application extension block near the start of the file. Asking for a single play writes no block at all, which is the only unambiguous way to say "play once" — a block containing the number 1 is read as one play by some viewers and one repeat after the first by others. Counts above one are passed straight through and are approximate for the same reason, which is why the readout says "about".
Does the crossfade cost anything?
Every blend step is a whole extra frame in the file, at full size. Two blend steps between six looping images turn 6 frames into 18 (6 + 6 × 2), roughly three times the bytes; played once, 16. That is not a reason to avoid it, but it is a reason to see the number: the size estimate counts the blend frames, and the crossfade slider will not let you exceed 200 encoded frames because past that the encode takes longer than anybody will wait for a file nothing renders smoothly.
Is anything uploaded?
No. The images are decoded, composited onto a canvas and encoded to GIF in this tab. There is no server in the path — this whole site is static files — so there is nowhere for them to go. The encoder is 11.6 KB gzipped and is fetched only when you build, so reading this page costs you nothing.
Should this even be a GIF?
Often not, and it is worth saying so on a page whose job is to make them. The same animation as an MP4 or a WebM is routinely ten to fifty times smaller and plays more smoothly, because those formats only store what changed between frames. GIF is the right answer when the destination will not take anything else: a chat or forum that only accepts image uploads, an old email client, a document, a README. If your destination accepts video, use video.