Every GIF tool shows you a different pile of sliders when a file is too big to send. I wanted to know which of them actually move the byte count. The sample is MORPH.gif, 675×599, 10 frames, 3,003,893 bytes, by Kowloonese on Wikimedia Commons under CC BY-SA 3.0. Everything below comes from this one clip, one machine (Apple M4, desktop Chromium), single runs, so read the numbers as "this clip" and not as a rule for GIFs in general.
Cutting colors moves the size the most
I used the animation tool in ImgIng https://imging.ai/ on desktop Chromium, GIF output, dithering off, and changed only the color count. The default is 256 colors and gives 1,525,126 bytes. At 128 colors it was 1,337,247, at 64 colors 1,083,830, and at 32 colors 811,310. That is roughly a halving between 256 and 32. For comparison, ezgif's lossy mode at its default level 30 produced 505,987 bytes from the same file and iLoveIMG's page, which has no settings, produced 656,903, so the default ImgIng output was the largest of the three. The settings differ between tools, so this is not a ranking, and the colors setting is what closes part of the gap on the ImgIng side.
Turning dithering on makes the file bigger
With dithering on (Floyd–Steinberg), the same four color counts gave 1,110,431 at 32 colors, 1,339,435 at 64, 1,475,692 at 128 and 1,535,115 at 256. Against dithering off that is +36.9%, +23.6%, +10.4% and +0.7%. In the tool, the fewer colors you keep, the more dithering cost.
I rebuilt the same comparison outside the tool, with Pillow for the palette and gifsicle -O3 for the final file, on a copy of the clip where every frame was blurred slightly to remove the noise already baked into the original. The gap there was +32% to +50% across 32 to 256 colors. Counting the output codes of a GIF-style LZW encoder, 32 colors went from 418,303 codes with dithering off to 628,637 with it on, a rise of 50.3% that matches the file size rise of 50.4%. My explanation is that dithering scatters single-pixel noise, which breaks up the repeated runs LZW relies on. That part is an inference, not something I verified. The +0.7% at 256 colors in the tool is also unexplained; I suspect the original is already close to 256 colors, but I did not check.
The quality slider did nothing for GIF
The tool has a quality slider. At 30, 50, 74 and 100 the GIF output was 1,525,126 bytes every time. I read that as the slider belonging to the other output formats, which is a guess; what I saw is only four identical sizes. For GIF the knobs that did something were color count, dithering and, according to the panel, frame optimization, frame drop and scale.
Frame drop and scale were checked outside the browser
I did not run frame drop or scale inside the tool. A supplementary run on the same clip with Pillow and gifsicle, starting from the blurred copy at 256 colors and dithering off (1,364,178 bytes), gives a feel for them:
| Change | Bytes |
|---|---|
| 32 colors | 572,768 |
| Keep every other frame | 722,755 |
| Scale to 50% | 456,136 |
| 32 colors and scale to 50% | 203,744 |
Dropping every other frame saved 47.0% and halving the dimensions saved 66.6%. On this clip frame drop is expensive in another way: all ten frames change and the whole animation lasts one second, so half the frames means half the time you are looking at an old picture. In the same supplementary run, doing the 32-color step before or after the 50% scale changed the result by only 987 bytes.
Lossy in ezgif went furthest on this clip
ezgif processes in the browser by default, with a "Local processing" box ticked on its optimize page (checked 2026-10-30). On the same file its Lossy GIF mode gave 505,987 bytes at level 30, 427,190 at level 60 and 331,817 at level 200. When I ran gifsicle on the original with --lossy=30 and nothing else, the result was 1,511,531, so ezgif must pass more than that one option. I did not find out which. During the compress step in ImgIng I saw no request carrying the file, which is only this run and not a claim about every feature.
Two more runs use gifsicle's own color reduction on the original clip, with dithering off and then forced on. That is a different condition from the tables above, so do not compare the numbers across sections:
$ gifsicle -O3 --colors 32 --no-dither IN.gif -o small.gif; stat -f%z small.gif
426315
$ gifsicle -O3 --colors 32 -f IN.gif -o small.gif; stat -f%z small.gif
1005103
Phones and tablets only get image compression on the ImgIng site; for animation it asks you to open a desktop browser.
Top comments (0)