A ten-second clip that is 3 MB as an MP4 can be 30 MB as a GIF, and most places you want to post it stop at 8 MB. The format is from 1989 and cannot be made efficient, but its size is governed by just four settings, and once you know what each one costs you can land under any limit on purpose rather than by trial and error.
Why GIFs get big
A modern video codec stores one complete picture every second or two and then describes only what changed between frames, which is very little in a talking head and not much even in a moving shot. A GIF has no idea what the previous frame looked like. Each frame is stored as an indexed image: every pixel is a number that points at one of at most 256 colours in a palette, and that grid of numbers is squeezed with LZW, a dictionary compressor from 1984 that is good at repeated runs and poor at anything that looks like photographic texture.
So a GIF’s size scales with three multiplied quantities: the number of frames, the number of pixels in each frame, and the number of bytes LZW needs per pixel, which depends on the palette size and on how much noise there is to compress. Sound, by the way, is simply not part of the format.
Encoders do have one trick: frame differencing. Pixels that did not change can be marked transparent so the previous frame shows through, and only the changed region is stored. It helps a great deal for screen recordings where most of the frame is still, and hardly at all for footage from a hand-held camera where every pixel shifts a little each frame.
The four knobs and what each costs
Width (and with it height) is the biggest lever because it acts in two dimensions. Going from 640 to 480 pixels wide removes 44% of the pixels; 480 to 320 removes another 56%. Since chat windows show GIFs at a few hundred pixels anyway, 480 is a sensible default and 320 is fine for reactions.
Frame rate is linear: 24 fps is exactly twice the frames of 12 fps. Motion reads as smooth at 12 to 15 fps in a chat window; 10 fps is acceptable; 5 fps suits a slideshow. ClipHeron picks frames by timestamp from the source, so a 30 fps clip at 12 fps keeps every 2.5th frame rather than stuttering.
Colours set the bits per pixel before compression: 256 colours need 8 bits, 128 need 7, 64 need 6, 32 need 5. The visible cost is banding in smooth gradients and slightly flatter skin tones. 128 is a good default for footage; 64 is often enough for screen recordings; 32 is for graphics with a handful of flat colours.
Dithering is the hidden multiplier. It scatters two nearby colours to imitate a third, which hides banding beautifully and creates exactly the kind of pixel-level noise LZW cannot compress. Turning it off on a screen recording can halve the file. Leaving it on for a face is usually worth the bytes.
The arithmetic, with numbers
A rough but useful model: bytes ≈ frames × pixels per frame × (bits per pixel ÷ 8) × an LZW factor. The LZW factor is about 0.4 for dithered footage, 0.3 without dithering, and lower for flat graphics. Apply it to a ten-second clip:
| Settings | Frames | Pixels | Bits/px | Estimate |
|---|---|---|---|---|
| 640×360, 15 fps, 256 colours, dither on | 150 | 230,400 | 8 | about 10.5 MB |
| 480×270, 12 fps, 128 colours, dither on | 120 | 129,600 | 7 | about 4.1 MB |
| 320×180, 10 fps, 64 colours, dither off | 100 | 57,600 | 6 | about 1.0 MB |
The first row is over the limit; the second, which is the tool’s default, is comfortably under; the third is small enough for anywhere. Notice that the second row kept most of the visible quality (480 pixels, 12 fps, 128 colours) for a 60% saving, almost all of it from width and colours. Doubling the clip to twenty seconds doubles every row, which is why duration is the knob to reach for before any of the others.
These are estimates; the real figure depends on the content. A static screen recording compresses far better than the model suggests, and confetti far worse. That is why a good tool measures a sample with the real encoder before promising a size.
A repeatable recipe for 8 MB
- Cut the range to the moment. Five to ten seconds is a GIF; thirty is a video pretending. Every second you remove is bytes for everything else.
- Start at 480 pixels wide, 12 fps, 128 colours, dither on. For most clips under ten seconds this already fits.
- If it is over, drop colours to 64 first. It is the change people notice least.
- Then frame rate to 10. Motion still reads as motion.
- Then width to 320. Only now does the picture visibly shrink.
- Then dithering off. Especially effective for screen recordings; a little banding may appear in skies and skin.
- Still over? Shorten the range. No setting rescues a long GIF.
Letting the tool do the search
The ClipHeron GIF maker runs exactly that recipe when “Fit under” is on: colours first (256, 128, 64), then frame rate (24, 15, 12, 10), then width (640, 480, 320), then dithering off. At each step it encodes a three-second sample with the real GIF encoder to measure bytes per second, so by the time the full encode runs the size is a measurement rather than a guess. If the full output still overshoots the limit by more than 3%, it takes one more step and encodes again, and it always reports the final size in bytes. The live estimate on the page uses the model above until the sample has run, and says so.
It also writes GIFs properly: a global palette quantised from a sample of frames (median cut), frame delays in whole centiseconds with the rounding error carried forward so a 12 fps GIF does not drift, the NETSCAPE 2.0 loop extension, and no comment or application blocks that might leak a file name.
When to send an MP4 instead
For anything longer than about fifteen seconds, anything with sound, or anything you want to look sharp, an MP4 is the right file. At 1 to 2 Mbps a 1080p MP4 of a thirty-second clip is 4 to 8 MB and looks like the original; the same clip as a GIF under 8 MB would be 320 pixels wide at 10 fps with 64 colours. Every chat app autoplays and loops a short MP4 just like a GIF. Use the trimmer to cut the range losslessly, then the compressor if it needs to be smaller, and keep GIFs for what they are good at: short, silent, looping reactions and demonstrations.
Make a GIF that fits under 8 MB
Frequently asked questions
Why 8 MB?
It is Discord’s attachment limit without Nitro, and about the largest GIF that Slack, Teams and most chat previews animate smoothly. Larger GIFs are often shown as a static image or a link.
Does a GIF have sound?
No. The format has no audio at all. If the sound matters, send an MP4; every chat app autoplays and loops a short MP4 the way it does a GIF.
Why does my GIF look grainy?
That is dithering: the encoder scatters two nearby palette colours to imitate a third. It hides banding in gradients at the cost of visible noise and a larger file. Turn it off for screen recordings and flat graphics; keep it on for faces and skies.
What frame rate should a GIF be?
10 to 15 frames per second reads as smooth motion for most content. 24 fps doubles the size over 12 fps for a difference few people notice in a chat window. 5 fps suits slideshows and reaction clips.
Is a smaller GIF lower quality than a bigger one?
Not necessarily. A 480-pixel GIF with 128 colours and no wasted frames can look better than a 640-pixel one with 256 dithered colours viewed at the same size, because the viewer scales both to fit anyway.
Sources
This guide explains how things work in general terms. Platform limits and codec support change; the figures were checked on the date shown above. Spotted something out of date? Email errors@clipheron.com and we will check it against the source.