Video to GIF: the bytes per pixel per frame, measured

Our video-to-GIF tool estimates the output size from a constant of 0.45 bytes per pixel per frame and says the figure will be wrong by a factor of two either way. We measured how wrong, and on what.

The unit

Bytes per pixel per frame is the size of a GIF divided by its width, height and frame count. It isolates the thing GIF is bad at — storing every frame as a complete 8-bit image compressed with LZW, with no reference to the frame before — from the choices that merely scale it. Halving the width quarters the file at any value of this number; the number itself is decided by the picture.

The measurement

Two four-second clips, both decoded to 50 frames at 480 × 270 and 12.5 frames per second: a photograph with a slow pan and zoom, so that every frame differs from the last, and a Chromium screen recording of two pages on this site being scrolled. Each frame set was encoded in headless Chromium with modern-gif 2.1.0 — the encoder behind the tool — at five palette sizes, with and without Floyd–Steinberg dithering. The same 50 frames were also encoded with FFmpeg 6.0 as H.264 at CRF 23 and CRF 18, and as VP9 at CRF 33. Run on 1 October 2026.

Palette	Moving photograph	Bytes per pixel per frame	Screen recording	Bytes per pixel per frame
255 colours, dithered	4,171,930 B	0.644	716,151 B	0.111
255 colours, no dither	4,188,639 B	0.646	685,764 B	0.106
128 colours, dithered	3,674,083 B	0.567	685,507 B	0.106
64 colours, dithered	3,115,969 B	0.481	637,659 B	0.098
32 colours, dithered	2,569,888 B	0.397	549,810 B	0.085
16 colours, dithered	2,010,333 B	0.310	506,418 B	0.078

The first row is what the tool ships, since it encodes at 255 colours with dithering on. FFmpeg’s own palette encoder produced 3,670,375 bytes and 726,687 bytes for the same two inputs at 256 colours — within 12% of modern-gif on the photograph and 1.5% on the recording, so the numbers describe the format rather than one library.

The same frames as video

Encoding	Moving photograph	Screen recording
GIF, 255 colours, dithered	4,171,930 B	716,151 B
H.264, CRF 18	178,684 B	179,566 B
H.264, CRF 23	78,138 B	131,975 B
VP9, CRF 33	39,613 B	105,788 B

“A GIF is about ten times the MP4” is the figure usually given. On the photograph it was 53 times at CRF 23, 23 times even at CRF 18, and 105 times against VP9. On the screen recording it was 5.4 times. The photograph is the case where video codecs are at their best, because motion prediction turns a panning image into a few instructions per block; GIF has no such thing and pays for every pixel every frame.

What the palette buys

Cutting from 255 colours to 16 halved the photograph and took 29% off the recording. It is a real saving and it is the ugliest one available: banding on every gradient and posterised skin. Dropping the width from 480 to 340 saves the same 50% and is far less visible, which is why our tool exposes width and frame rate before it exposes anything else.

Dithering cost almost nothing in bytes — under 1% on the photograph, 4% on the recording — and two to four times the encoding time. At 16 colours the dithered and undithered files were the same size to the byte on both clips.

The estimate against the measurement

At 0.45 bytes per pixel per frame the tool would have estimated 2.92 MB for both clips. The photograph came out 43% over that and the screen recording 75% under. A single constant cannot describe a format whose ratio is set entirely by the content, which is why the estimate is labelled as loose and the real figure is printed beside it afterwards. Measured on a single frame, the photograph cost 0.668 bytes per pixel and the interface 0.224 — so if you need to know in advance, one frame through the encoder is a better predictor than any constant.

The short version

For photographic footage, expect around 0.6 bytes per pixel per frame and a file fifty times the MP4; for flat interface footage, around 0.1 and five times. Width is the lever; palette is the last resort; and past a few seconds a GIF is a video wearing the wrong extension.