Why Is My GIF So Large?

A GIF's size is roughly its frame count × the pixels in each frame × how hard those pixels are to compress, because GIF squeezes each frame on its own with LZW and has no real motion compression. That is how a few seconds of video become several megabytes. On our 3-second, 480 × 270 test clip, Playcut's GIF encoder produced 2,042 KB where an H.264 video of the same frames needed 59 KB.

Below are the short answer, a table measuring what each factor costs, the reason GIFs lose so badly to MP4, the hidden causes such as dither noise and per-frame palettes, and the fixes in the order that saves the most.

Why is my GIF so large? The short answer

Three things decide almost every GIF's size: how many frames it has, how many pixels each frame holds, and how busy those pixels are. The first two multiply. The third decides how well the compression inside each frame can work, and it is why two GIFs with identical dimensions can differ in size by a factor of twenty or more.

• Too many frames: GIFs are often exported at the source's full frame rate and length.
• Too many pixels: a screen recording or phone clip exported at its original size.
• Busy pixels: film grain, gradients, dithering and camera movement.

The format explains why. The GIF89a specification, published by CompuServe in 1990 and still the definition of the format, stores each frame as indices into a colour table of at most 256 entries and compresses those indices with LZW. Between frames it allows only two savings: a frame can cover just the rectangle that changed, and unchanged pixels can be left transparent so the previous frame shows through. Only some encoders use them.

What each factor costs, measured

We measured each factor instead of asserting it. Starting from one synthetic clip, 480 × 270 at 15 fps for 3 seconds with 256 colours, a textured gradient background, a moving disc and a fixed camera, we changed one setting at a time. Every version was encoded with Playcut's browser GIF engine, the same code the GIF tools on this site run.

Sizes in KB (1 KB = 1,024 bytes). Change is against the base clip unless the setting names another file. * Playcut's encoder writes every frame whole, so the last row was built separately with the same GIF library it uses, to show what the unchanged-pixel optimisation is worth.

Frames scale almost perfectly: three times the frames at 30 fps cost three times the bytes of 10 fps, and doubling the length doubled the file. At this size the clip grows by about 681 KB for every second of animation. Pixel area is the biggest single lever, though not a linear one: four times the pixels cost 2.7 times the bytes here, because a larger frame gives LZW longer runs to repeat.

Colours matter less than people expect at the top and more at the bottom. Going from 256 to 128 colours saved 8%, while 32 colours saved 47% at a visible cost in banding. Content matters most of all: the same motion over a flat background made an 85 KB file, 24 times smaller than over the textured one.

The clip is synthetic and seeded, so every run produces the same bytes. Your own footage will land at different numbers, but these are the relationships to expect.

Why GIFs are larger than MP4

An MP4 is smaller because its codec predicts each frame from the frames around it. H.264, the ITU-T standard inside most MP4 files, splits the picture into blocks, finds where each block came from in a reference frame, and stores only that motion plus a small leftover difference. GIF can only store each frame as an image of its own.

Even the best case for GIF, a fixed camera with unchanged pixels skipped, came out about three times the size of the H.264 file, and the panning clip was 29 times larger. H.264 here is lossy while the GIF is exact within its palette, so the sizes are not quality-matched. Grain is where the video encoder quietly smooths away detail that the GIF keeps.

The GIF compressor's explainer summarises the same mechanism. The full comparison with animated WebP and APNG, measured on these clips, is on the GIF vs WebP vs APNG vs MP4 page.

The hidden causes: dithering, gradients and per-frame palettes

Frames and pixels are easy to see in a file's properties. The causes below are not, and they are behind many "why is this 2-second GIF 8 MB" surprises.

Dither noise

Dithering scatters pixels of neighbouring palette colours to fake the shades a 256-colour palette lacks, which is how a gradient avoids visible bands. It looks smoother, but it replaces flat runs with noise that LZW cannot compress. In our test, adding Floyd–Steinberg dithering to the 64-colour version made it 30% larger, and at 32 colours 41% larger.

Playcut's GIF tools do not dither today, so their files avoid that cost. The trade-off is banding on gradients at 32 colours and below, which is why the GIF compressor warns of banding on its 32-colour preset and marks 16 colours for line art and logos only.

Camera motion and grain

Motion itself is cheap for Playcut's encoder, because it stores every frame whole either way: the panning version was only 1% larger than the fixed-camera one. Motion gets expensive for optimising encoders, which save space by skipping pixels that did not change. On the fixed-camera clip that trick cut the file by 91%; on the pan it made the file 10% larger, because nearly every pixel changed.

Film grain and sensor noise are worse still, because every pixel changes on every frame and each frame is noisy inside. Adding grain made the fixed-camera clip 51% larger, and the only big levers left after that are fewer pixels and fewer frames.

A new palette every frame

A GIF can carry one global colour table or a local table for each frame. Local tables let every frame choose its own best 256 colours, which helps when a clip cuts between very different scenes, but each one adds up to 768 bytes and can make flat areas shimmer as their colour shifts slightly between frames. In our test the per-frame version was 2% larger than the shared palette.

Why compressing can make a GIF bigger

Many GIFs from optimisers already use the unchanged-pixel trick. Decode one and re-encode it with an encoder that writes every frame whole, and the saving is gone. Playcut's GIF encoder works that way today: re-encoding our 176 KB optimised file through it produced 2,041 KB, 11.6 times larger.

The GIF compressor and size reducer report a result like that as "% larger" rather than hiding it. When you see it, keep your original. If that is still too big, crop or scale down, since fewer pixels shrink every frame, and compare the result with the original before you replace it.

Fixes in the order that saves the most

Apply these in order and check the size after each step. The first three usually do most of the work.

1. Crop to what matters. Removing dead space cuts pixels from every frame; the animated GIF cropper explains why a crop often shrinks the file sharply.
2. Scale down. Halving width and height leaves a quarter of the pixels; 480 to 240 pixels wide saved 68% in our test.
3. Cut frames or length. Going from 15 to 10 fps saved 33%, and every second you trim removes its share.
4. Reduce colours. 128 colours is rarely visible, and 64 suits screen recordings and flat art.
5. Remove noise before converting. Denoise grainy footage and avoid dithered exports.
6. Switch to video where you can. For the fixed-camera and panning clips, the MP4 was about 29 to 35 times smaller than the GIF from Playcut's encoder. The GIF to MP4 converter does that conversion in your browser.

To hit a specific number, such as a platform's upload limit, the GIF file size reducer searches for settings that fit a byte budget. Both GIF tools run in your browser tab and never upload the file. The limits themselves, dated and sourced, are in GIF size limits by platform.

If you switch to video, the video bitrate calculator suggests a bitrate for the resolution and frame rate, which sets the MP4's size before you export.