Hitting an exact GIF file size in the browser without a slow retry loop

Siva Bollin — Sat, 10 Oct 2026 05:16:13 +0000

Most GIF compressors give you a quality slider and leave you to guess. That is a bad fit for the usual reason people shrink a GIF: a platform has a hard limit. Discord emoji and Slack uploads come with hard size and frame limits. You do not want "roughly smaller", you want "under N bytes, as good as possible".

I built a browser-only GIF compressor around that idea. You enter a target size, and it works out the settings. Everything runs on the user's machine. The encoder is gifsicle compiled to WebAssembly, running in a web worker so the page stays responsive. This post is about the search problem on top of it, because that is where the interesting decisions were.

The problem: encodes are slow, the search space is big

The knobs that change output size are width, frame count, color count, and lossy strength. A naive approach is a binary search on one knob. But each full-size encode in WASM is slow (a couple of seconds on my machine for larger GIFs), so ten iterations is already a bad experience, and one knob is not enough.

Step 1: try the cheap knobs first, in order of damage

The search goes from least to most visible damage:

Lossy compression alone, from gentle to strong.
Fewer colors (128, then 64, then 32).
Shrinking the width, and if that would cut the width too far, dropping frames first.

Before walking each ladder, it encodes once with the strongest settings for that step. If even the strongest setting misses the target, the gentler ones cannot fit either, so the whole ladder is skipped. That one check saves several full-size encodes in the common case where the target is far away.

Step 2: a half-width probe

For the resize step, I do not want to run slow full-size encodes just to find out that none of them fit. So the first encode is at half the width, which is about four times fewer pixels and much faster. That single probe gives a size at a known width.

From experience with gifsicle on my own sample GIFs, output size scales roughly like this:

bytes ∝ width^1.85 × frames^0.85

Those exponents are empirical, fitted on my samples with -O3 --lossy=120 --colors=64, not a law. They are good enough to turn the probe into a starting guess:

function predictWidth(probeWidth, probeBytes, targetBytes, frameStep) {
  const frameFactor = Math.pow(frameStep, -0.85);
  return probeWidth * Math.pow(targetBytes / (probeBytes * frameFactor), 1 / 1.85);
}

The same probe also answers a cheaper question first: could any full-size setting plausibly fit? If the predicted full-size output, even after halving it for the strongest color and lossy settings, is still over the target, the full-size ladders are skipped entirely.

Step 3: a bracketed search that refines the model as it goes

The estimate is only a guess, so it is refined with a short search. It keeps a bracket: the widest width known to fit and the narrowest known to miss. After each encode it fits the exponent again from the last two measurements (a log-log secant step), and falls back to 1.85 if the slope looks implausible. It aims about 2% under the target so the next attempt tends to land inside the budget, and it stops when another encode would gain less than about 3% width.

let slope = 1.85;
if (prev && prev.width !== width && prev.bytes !== output.length) {
  slope = Math.log(output.length / prev.bytes) / Math.log(width / prev.width);
  if (!Number.isFinite(slope) || slope < 1 || slope > 3) slope = 1.85;
}
next = width * Math.pow((targetBytes * 0.98) / output.length, 1 / slope);

In practice this converges in a handful of encodes. I have not benchmarked it against a plain binary search, so I will not claim a specific speedup, only that the starting point is much closer than the midpoint.

Dropping frames without making the animation faster

Sometimes shrinking width alone would blur the GIF too much. Dropping frames is the other lever, but a naive "delete every second frame" halves the duration, so the animation plays twice as fast.

The fix is to add the delay of each removed frame to the frame that is kept. If you keep every other frame, each kept frame stays on screen for its own delay plus the delay of the frame that was dropped after it. The total duration stays close to the original, and the function reports the remaining error so it can be checked in tests.

Two details bit me here:

GIF delays are in hundredths of a second, so every compensated delay has to be rounded. Each kept frame gets the rounded sum of its group, so the error stays small, but it is not zero.
Browsers play delays of 0 to 10 ms as 100 ms. If you compute the frame rate from the raw numbers, a GIF with many zero delays looks much faster than it plays, and you drop frames you could have kept. The fps estimate treats those delays as 100 ms.

There are limits on how far it goes: it never goes below 6 fps from optional frame dropping, never drops beyond keeping every third frame (unless a platform frame cap forces more), and prefers dropping frames over shrinking below half the original width.

Platform rules go in before the search. A frame cap forces a minimum frame step, and the Discord emoji preset is bounded to a 128x128 box and about 250 KB, so the candidates respect those limits from the start.

A WASM gotcha worth knowing

Calling gifsicle's CLI entry point repeatedly in one module instance worked until one call failed. After a failed run its global option state stayed dirty and every later call failed too. The fix is to throw away the cached module whenever an exit code is non-zero and create a fresh one on the next task.

What I have not verified

I have not compared compression ratios or speed against other tools, and the size model comes from my own sample set, so it may be off on unusual GIFs (huge flat-color animations, for example, or screen recordings). If you have a GIF that lands far from its target, I would like to see it.

The tool is free, and nothing is uploaded: https://compressgifonline.com

How to Compress Large GIFs Under 8MB for Discord Without Uploading to Servers

Siva Bollin — Wed, 23 Sep 2026 02:12:34 +0000

If you've ever tried to share an animated meme, gameplay highlight, or custom emote in a Discord channel, you've likely hit this frustrating wall:

"Your files are too powerful! Max file size is 8.00 MB." (or 256 KB for custom server animated emojis).

Typical online GIF compressors ask you to upload your personal clips to remote servers, queue them in line behind dozens of other users, and spit out watermarked or severely downscaled files. If the GIF contains private game captures, team demos, or unreleased assets, uploading them to third-party cloud servers poses real privacy concerns.

Here is how to compress bloated GIFs down to the exact Discord file size limits directly in your browser—with zero server uploads and zero privacy risks.

Why GIFs Get So Bloated

Unlike modern video formats (MP4, WebM, AV1), the GIF standard was invented in 1987. It does not utilize modern temporal compression. Instead, file sizes explode due to three factors:

Color Depth: Each frame stores a 256-color palette. Complex gradients or photographic scenes inflate palette data quickly.
Resolution & Dimensions: Discord chat displays animated emojis at 128×128 pixels, but creators often export them at 512×512 or higher.
Redundant Inter-frame Data: Unoptimized GIFs redraw the entire frame canvas each tick rather than only updating moving pixels.

Step-by-Step: Compressing for Discord in Under 10 Seconds

You can use the free web tool Compress GIF Online, designed specifically for privacy-first, client-side media processing:

1. Open the Tool

Navigate to Compress GIF Online (or jump directly to the Discord GIF Compressor dedicated preset).

2. Drag & Drop Your GIF

Drop your file into the compressor. Notice that processing starts immediately—no network progress bar or cloud upload happens. All processing runs 100% locally within your browser sandbox.

3. Choose the Discord Target Mode

For Custom Emojis: Select the Discord Emoji (<256KB) preset. It automatically constrains the file size safely under 250 KB and scales dimensions to 128×128 while preserving transparent edges.
For Chat Attachments / Memes: Select Target Size mode and type in 8 MB (or 10 MB depending on your Discord Nitro tier). The optimization algorithm automatically balances lossy palette reduction and frame dithering to hit your target size without muddying visual quality.

4. Preview & Download

Review the real-time split-screen comparison: inspect transparency, frame rate, and playback fluidity side-by-side. Click Download, and your optimized GIF is ready to drop straight into Discord.

Watch the Video Demo

Here is a quick walkthrough showing a large GIF compressed down to Discord requirements in just a few clicks:

Why 100% Client-Side Processing Matters

Zero Cloud Uploads: Your media never leaves your local computer or device. Ideal for confidential team screenshots, private gameplay, or unreleased assets.
No File Size Caps or Waiting Queues: Traditional web compressors impose strict 15MB or 30MB upload limits because server compute is expensive. Client-side processing uses your machine's own CPU, allowing large source files without queues.
Instant Turnaround: No uploading latency, no downloading latency.

Try it out next time you need to fit a high-energy GIF into your Discord server: https://compressgifonline.com

DEV Community: Siva Bollin