Why GIFs balloon in the first place
GIF compression is LZW, an algorithm published in 1984, wrapped around frames stored as indexed pixels. There is no motion estimation, no notion that frame 40 looks almost exactly like frame 39. A modern video codec stores one real picture and then compact descriptions of change; a naive GIF stores every frame as a full picture. That alone explains most of the horror stories.
Three multipliers stack on top. Dithering, which fakes gradients by scattering single pixels, is poison to LZW, since scatter is exactly the kind of noise its run-based tricks cannot squeeze. Screen recordings arrive at 30 or 60 fps, two to four times the frame budget a GIF needs. And width is quadratic: a 1200-pixel-wide capture carries four times the pixels of a 600-pixel one. Multiply a few of those together and an eight-second clip lands at 20 MB without anyone doing anything wrong.
The part that happens automatically
Before you touch a single control, the encoder in the tool runs lossless inter-frame optimization on every export. Frames identical to the previous one are not stored again; they merge into a single frame shown for longer. Frames that do change are cropped down to the rectangle that actually changed, and inside that rectangle, pixels that stayed the same are marked transparent so they cost almost nothing.
For static-heavy material, terminal sessions, UI walkthroughs where only a cursor moves, slides with one small animation, this alone is a large win, and it costs zero quality by definition: the decoded result is pixel-identical to the naive version. There is no dial for it and nothing to configure. It is simply how the encoder writes GIFs.
Extra Compression, and what it honestly trades
Under All settings sits an Extra Compression dial with three positions: Light, Medium, Strong. It applies lossy LZW in the gifsicle and giflossy tradition, letting the encoder nudge pixel runs toward patterns it has already seen so they pack into fewer bits. Medium typically lands 30 to 50 percent smaller than the same export without it.
The cost is mild grain, a faint patterned noise most visible in flat color fields and smooth gradients. On live footage and photographs it usually disappears into the material. On UI captures with fine text, stay at Light and read the small type in the preview before you commit. Strong is for hard ceilings, a forum limit or an email budget, where a little grain beats the file bouncing.
Four levers, in the order they pay
When the automatic pass and the dial are not enough, four controls do the real work, and the live size estimate, measured by encoding a few real frames of your actual GIF, reacts to each one:
- Trim. Frames are the raw cost. Cutting a six-second loop to the three seconds that matter halves the file before any other setting moves.
- Width. Pixels scale with the square: 800 pixels wide down to 480 drops roughly two thirds of the pixel data.
- Frame rate. 24 fps down to 12 halves the frame count, and most loops read fine anywhere from 10 to 15.
- Colors. 256 down to 128 or 64 shrinks every frame's data. Footage rarely misses the difference; flat UI almost never does.
The deeper recipe, including dithering choices, lives on the small-file GIF page. The levers are the same whether the source was a video or a finished GIF someone handed you.
Recompress the sensitive ones with the wifi off
Plenty of GIFs that need shrinking are exactly the ones that should never touch a stranger's server: the HR walkthrough with employee names in the corner, the finance dashboard, the unreleased product flow. Every conventional optimizer works by uploading your file to be processed elsewhere. This one decodes, optimizes, and re-encodes on your own hardware; once the page has loaded, the network is decorative, and the job finishes in airplane mode. No account, no watermark, no retention policy to read, because nothing is retained. If the result is headed for an inbox, the GIF in email guide covers the size budgets mail clients actually enforce.
When to stop fighting the format
Some GIFs cannot be saved because they should not be GIFs. Photographic footage past ten seconds, heavy camera motion, anything where every frame changes every pixel: the format's 1980s physics lose. Flip Output Format to MP4 in Chrome, Edge, or Safari and the same edit exports as a silent H.264 file, routinely a tenth of the size; the GIF to MP4 page covers the trade. APNG is the other exit: usually heavier than a GIF, but with full 24-bit color, so gradients stop banding where the destination supports it. Autoplay-anywhere is the one reason left to insist on GIF, and it is sometimes a good one.