GIF is a 1987 format, and it shows in the file size
A GIF stores each frame as a separate 256-colour image compressed with LZW. There is no motion prediction, no transform coding, and no modern entropy coder — three of the four things that make an MP4 of the same clip roughly a tenth the size. Nothing about that is fixable by a better encoder, which is why every GIF tool on the internet is really a tool for deciding how much to give up.
The three settings above are exactly those trade-offs, and the panel keeps the frame count, the real playback rate and an estimated size in view as you move them. Width is the cheapest saving, because file size scales with area: going from 640 to 320 pixels wide cuts the output by roughly three quarters. Frame rate is next. Length is last, because a shorter GIF is a worse GIF and the other two are usually free.
The size figure is an estimate, and a loose one — LZW's ratio depends entirely on the picture, so flat interface footage packs several times tighter than a handheld shot of leaves. It is there to tell you which order of magnitude you are heading for before you spend twenty seconds finding out. The results panel prints the estimate next to the real number afterwards, so you can see how far off it was.
Why 12, 15 and 30 fps are not on the menu
GIF stores the delay between frames in hundredths of a second. That is the whole resolution available: 10 ms steps, no finer. 30 fps needs 33.3 ms, which cannot be written, so a file claiming 30 fps actually holds 30 ms and plays at 33.3. 15 fps becomes 14.3. 12 fps becomes 12.5.
Those are small errors that compound. Anyone lining a GIF up against a soundtrack, a screen recording or another animation will find the drift eventually, and by then the cause is three steps removed from the symptom. So the menu here offers only the rates a GIF can keep — 5, 10, 12.5, 20 and 25 — and prints the delay in milliseconds underneath, which is the number actually written into the file.
Frames are asked for by timestamp, not taken as they arrive
Modern video is not stored in the order it is shown. H.264 and its successors use bidirectional frames, which reference pictures both before and after themselves, so decode order and presentation order differ for most real footage. Safari up to version 26.3 returns decoded frames in the wrong order because of it; WebKit fixed it in the Safari 27 beta, which leaves a long tail of devices that have not been updated.
A GIF encoder that simply appends frames as the decoder produces them ships as "the animation is jumbled, but only on iPhones" — a defect that survives for months because nobody on the team can reproduce it. This tool asks the decoder for an explicit list of timestamps in ascending order instead, so the sequence is its own property rather than the decoder's. The same choice is what makes the frame rate exact regardless of the source file's own rate.
The one browser this page cannot serve is Firefox on Android, which has no WebCodecs at all and therefore no way to decode a video frame. It says so rather than spinning. The video-to-MP3 tool does work there, because audio decoding never needed WebCodecs. More in video & audio tools.