Where a GIF's bytes go
A GIF is a stack of frames, each squeezed by the same 1987 compression scheme, each limited to 256 colours. Two things decide its size: how much of each frame is stored, and how noisy the colours are. Storing only the changed part is free; reducing colours and frames is a trade, so it is yours to make.
- Lossless: changed rectangles only, transparency reuse, exact colour tables. Every displayed pixel kept.
- Fewer colours: one palette shared by every frame (median cut), optionally dithered, 2 to 256 colours.
- Identical consecutive frames merged into one, their delays added together.
- Every second or third frame kept, delays summed, so the clip runs as long as before.
- A smaller long edge for every frame.
- A byte cap: lossless first, then the palette searched, floor first, in at most eight encodes.
- Or save as an animated WebP: same frames, timing and loop, written by libwebp (lossy or lossless) in a background worker.
No lossy LZW, and WebP is not for everywhere.
Lossy LZW (the gifsicle trick) is not offered: no licence-clean implementation is part of this build. Animated WebP plays in every current browser but not in every chat app, email program or editor; the GIF option stays the default for that reason.
Questions people arrive with
Will my GIF still animate?
Yes. Every frame is decoded, composited the way a browser shows it, and written back with its own delay. The loop count is copied across, and the result line prints frames, running time and loop before and after so you can see nothing was dropped.
How can it get smaller without losing quality?
Most GIF writers store every frame whole. This one stores only the rectangle that changed since the previous frame, marks the unchanged pixels inside it as transparent so the previous frame shows through, and gives each rectangle an exact colour table. When that is lossless, the page says so; when a rectangle needed more than 255 colours, it says that instead.
What do the other settings cost?
Fewer colours band gradients and filmed footage. Keeping every second frame halves the frame count and adds the dropped delays to the frames kept, so the running time is the same but motion is choppier. A smaller long edge shrinks every frame. None of them is applied unless you choose it.
Should this GIF be a video instead?
Often, yes. A clip filmed with a camera, longer than a few seconds, compresses many times smaller as an MP4 or WebM. GIF earns its place for short loops, flat colours and places that accept nothing else. This site does not convert to video.
Should I save it as an animated WebP instead?
If it is going on a web page, usually yes. Choose Animated WebP: the same frames, timing and loop are written by libwebp, lossy or lossless, and the result line shows the measured size next to the GIF's. Every current browser plays animated WebP; some chat apps, email programs and older image editors still only animate GIFs, so keep the GIF where it must open everywhere.
Is there a size limit?
The frames are held in memory one or two at a time, but the whole clip may total no more than 400 million decoded pixels (frames × width × height). Past that the page says so before it starts.
Elsewhere on this site
- Check image size in KBA GIF's frames, running time and loop, read without changing it.
- Compress PNGFor a still graphic, PNG with a small palette usually beats a one-frame GIF.
- Compress image to KBA still picture to a byte cap.
