How Big Is a GIF? We Measured Instead of Guessing.

What's in the frame beats every setting on the panel

Before touching a single dial, know this: the same duration, dimensions, and settings produced a 45x size difference depending on what the pixels were doing. A four-second screen capture (flat colors, sharp edges, most of the frame holding still) came out at 41 KB. Four seconds of camera-style footage (gradients, motion, grain in every pixel) came out at 1.8 MB. Same encoder, same 480 pixels wide, same 15 fps, same everything.

The reason is baked into the format. GIF compresses runs of identical pixels well and merges frames that repeat, so interfaces are nearly free. Grain and gradients defeat both tricks at once: every pixel differs from its neighbor and every frame differs from the last. If your clip is UI, relax, the settings barely matter. If it's footage, every section below is your budget meeting.

Frame rate: linear on footage, surprisingly cheap on UI

On camera footage, frames cost what they say on the tin: going from 5 fps to 30 fps multiplied the file by 5.7x, almost perfectly linear. On the screen capture the same jump only cost 2.5x, because this encoder merges identical frames and stores only the region that changed, and most of a UI recording is identical frames.

The takeaway: 10 to 15 fps is the sweet spot we keep recommending, and now you can see why. On footage, 15 fps costs 56% of what 30 fps costs and nobody watching a loop can tell. On a screen recording you can afford 20 fps for smooth cursor motion and barely feel it.

Width: the lever with a square attached

Width is really area, and area is width squared. Halving the width from 480 to 240 pixels didn't halve the footage file, it cut it to 0.31x. Pushing up to 800 pixels cost 2.5x. This is the most powerful dial you control directly, and it's the first one to reach for when the estimate looks scary.

Most places a GIF lands (a chat message, a README, an email column) render around 400 to 600 pixels anyway, so pixels past that are weight the viewer never sees. Crop to the action first, then set width to the size it will actually display.

Colors: worth triple on footage what it's worth on UI

The palette dial rewards the content that needs it least gently. Dropping from 256 to 64 colors saved 38% on camera footage but only 10% on the screen capture, because flat UI colors compress beautifully at any palette size while gradients spend palette entries fast.

64 colors is the practical floor for footage before skin tones and skies start banding visibly. For UI recordings, honestly, leave it at 256; the savings aren't worth checking every button hover for posterized edges.

Extra Compression: auditing our own 30-to-50-percent claim

This site's Extra Compression dial (lossy LZW, the gifsicle trick) promises "typically 30 to 50 percent smaller." Since we were measuring anyway, we checked our own marketing. On camera footage the Medium setting delivered -42%, comfortably inside the claim. On the screen capture it managed only -10%, because flat content gives lossy matching very little to shave. So the claim holds for the clips that need it and we've now said the quiet part out loud for the ones that don't.

Medium is the setting to try first on any clip that shot over budget: on footage it bought back nearly half the file for grain most viewers never spot in motion.

GIF vs APNG, same clip, no contest on size

APNG exists for color fidelity, not for weight, and the measurements are blunt about it. The same four seconds came out 4.7x bigger as APNG for camera footage and 17.9x bigger for the screen capture. APNG has no 256-color palette, so gradients render clean where GIF would band; that is the one reason to pay its price.

The recipe, in the order the data says

Every dial above, ranked by measured payoff. Work the list top to bottom and stop when the estimate fits.

1. Crop and cap the width first. Bytes scale with pixel area, the strongest lever measured: 480px cost 0.40x what 800px did on footage. Set width to the size it will really display, usually 400 to 600 pixels.
2. Set the frame rate by content. Footage scales almost linearly with fps, so 10 to 15 fps is the budget zone. Screen recordings can afford more, since identical frames merge nearly free.
3. Trim to the seconds that earn their place. Camera footage measured about 461 KB per second at 480px and 15 fps. Every second you cut is half a megabyte back.
4. Turn on Extra Compression, Medium. Measured at -42% on footage. On UI captures it saves little, so skip it there and keep exact pixels.
5. Drop colors only for footage. 64 colors saved 38% on camera-style clips but just 10% on UI. Watch for banding, then stop.

How we measured, so you can argue with us properly

Two synthetic 960x540, 30 fps source clips, built to represent the two kinds of video people actually convert: a screen-recording stand-in (flat panels, rows of text, one-second scroll jumps, a moving cursor) and a camera stand-in (drifting gradients, a moving subject, per-frame grain). Each was trimmed to exactly 4.0 seconds and encoded by the same in-browser engine this site uses for every conversion, in headless Chromium, in July 2026. Settings held at the site defaults except the one being swept: 480px wide, 15 fps, 256 colors, Extra Compression off.

Your clip will not match these numbers exactly; no clip matches any benchmark exactly. The ratios are the point, and the ratios travel. We didn't publish MP4 numbers because the headless test rig lacks the hardware H.264 encoder the browser feature relies on, and we only print what we measured. If you want numbers for your own footage, drop it in the converter and watch the live size estimate respond as you move each dial; that estimate samples real encodes of your actual frames.