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: identical duration, dimensions, and settings produced an 11x size difference depending on what the pixels were doing. Four seconds of a screen recording (a web page full of text, a scroll every second, a moving cursor) came out at 183 KB. Four seconds of real camera footage (a product shot, soft light, a drifting camera) came out at 2.0 MB. Same encoder, same 480 pixels wide, same 15 fps.

The reason is baked into the format. GIF compresses runs of identical pixels and skips whatever didn't change since the last frame, so a recording that mostly holds still is cheap. Footage defeats both tricks: every pixel differs from its neighbor and every frame differs from the last.

Frame rate: close to linear on footage, a rounding error on UI

On camera footage, frames cost roughly what they say on the tin: going from 5 fps to 24 fps multiplied the file by 3.8x for 4.8x the frames. On the screen recording, 5 to 30 fps cost only 1.5x, because the encoder merges frames that repeat and stores just the region that changed, and most of a screen recording is the same frame twice.

10 to 15 fps remains the sweet spot for footage: 15 fps costs 65% of what 24 does, and nobody watching a loop can tell. On a screen recording, spend the frames; smooth cursor motion at 24 fps cost 13% more than 15 fps.

Width: the lever with a square attached

Width is really area, and area is width squared. Halving the footage from 480 to 240 pixels didn't halve the file, it cut it to 0.30x. Going up to 800 pixels cost 2.5x.

Text scales a little less kindly than footage (240 pixels was still 0.45x), because small type keeps its edges at any size. Most places a GIF lands, a chat message, a README, an email column, render it around 400 to 600 pixels wide anyway, so pixels past that are weight the viewer never sees. Crop to the action first, then set the width it will actually display at.

Colors: a real lever for text, not just footage

Dropping from 256 to 64 colors saved 46% on the footage and 38% on the screen recording. That second number surprised us. The soft edges on rendered text are dozens of in-between grays, and an encoder that keeps them crisp spends palette entries on every one.

64 colors is the practical floor for footage before skin and sky start to band. On screen recordings, try 128 first and look at the smallest text: when letters start to look stamped rather than smooth, step back up.

Extra Compression: auditing our own label

The Extra Compression menu says Medium makes files "10-50% smaller, some grain." Since we were measuring anyway, we checked. On the camera footage Medium delivered -12%, the bottom of that range. On the screen recording it found -27%, because flat UI and text give it long stretches of pixels it can safely merge. The top of the range belongs to smooth graphics and gradients.

This flipped since our first round of measurements, when Medium shaved 42% off footage. The engine behind it now judges each change by how visible it is rather than by a raw number, so on footage it mostly declines to make trades you'd notice. If footage is over budget, 64 colors buys back four times as much.

GIF vs APNG, same clip, no contest on size

APNG exists for color fidelity, not weight, and the measurements are blunt about it. The same four seconds came out 6.5x bigger as APNG for the footage and 33x bigger for the screen recording. APNG has no 256-color palette, so gradients render clean where a GIF might 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 down the list and stop when the estimate fits.

• Crop and cap the width first. Bytes follow pixel area: 480px cost 0.40x what 800px did on footage. Set the width it will really display at, usually 400 to 600 pixels.
• Set the frame rate by content. Footage scales close to linearly with fps, so 10 to 15 fps is the budget zone. Screen recordings can afford more, since repeated frames merge nearly free.
• Trim to the seconds that earn their place. The footage cost about 506 KB per second at 480px and 15 fps. Every second you cut is half a megabyte back.
• On footage, drop to 64 colors. Measured at -46%, the biggest single saving after width. Check skin and sky for banding.
• On screen recordings, try Extra Compression, Medium. Measured at -27% there. On footage it saved only 12%, so reach for colors first.

How we measured, so you can argue with us properly

Two clips, each exactly 4.0 seconds. A screen recording of one of this site's own guide pages, captured at 960x540 and 30 fps, with a scroll jump every second and a moving cursor. And real camera footage, our own soda product demo, 1920x1080 at 24 fps. Both went through the same in-browser converter you use, encoder v2, in headless Chromium, in October 2026. Settings held at the defaults except the one being swept: 480px wide, 15 fps, 256 colors, Medium quality, Extra Compression off.

These replace our July 2026 numbers, which came from synthetic stand-in clips and the previous engine. The newer encoder v2 keeps more detail: on the identical clips, the footage came out within 1% of the old size, and the screen recording roughly twice as large, because v2 keeps text edges crisp that v1 smeared. Your clip will differ; the ratios are the point, and they travel. MP4 isn't here because the test machine lacks the hardware encoder that feature needs. For your own footage, drop it in the converter and watch the live size estimate as you move each dial; it samples real encodes of your actual frames.