GIF vs WebM vs Lottie ZIP: 9 Real Exports Compared

Measured on 9 September 2026 in desktop headless Chrome 152.0.7977.83, using the real EasyLottie converter UI. Each source was uploaded separately for each format. Requested settings were 480 px longest edge, 24 fps, the full source duration, and a 450-frame ceiling. Green keying was enabled only for the green-screen shape; the other two kept their backgrounds.

This is one recorded run per source and format on a local development build, with library scripts prefetched and analytics blocked. Lottie ZIP and WebM used quality 0.7; GIF uses its own fixed palette settings, so the controls do not represent equal perceptual quality. Download the exact source and output files below, or inspect every field and SHA-256 hash in the public manifest.

The green-screen source contains 96 identical decoded frames. It demonstrates background removal, not motion. The UI source contains changing geometry; the 15-second test pattern starts at 60 fps and is resampled to 24 fps. Both GIF and Lottie ZIP retained the requested 96 / 96 / 360 frames and full 4 / 4 / 15-second durations.

The MediaRecorder WebM exports used wall-clock capture and did not always contain the requested frame count. The table reports their decoded frame counts, actual container durations, and count divided by duration; it does not label them exact 24 fps files. Repeat the export on your own device if precise timing matters.

Chrome decoded transparent background pixels and visible foreground pixels from the first green-screen output frame in all three formats. GIF contained only binary alpha. Lottie ZIP and WebM also contained partial alpha. This proves the alpha observed in these downloads on this Chrome version, not support in Safari, Firefox, native apps, or every other player.

For the unkeyed sources, the final GIF and Lottie outputs kept the first frame fully opaque. The WebM decoder reported partial alpha across those first frames, with a corner alpha value of 254 rather than 255; the raw pixel counts are included in the manifest. Inspect the actual exported image over the backgrounds you intend to use.

The table gives actual byte sizes for each output. The size difference depends on the source and requested settings, and WebM capture timing can change between runs. These synthetic examples do not establish a universal size ranking or a comparison at equal visual quality.

If you have a short clip and want it transparent on a web page, you are really choosing between three practical outputs. They differ most in transparency quality, browser support, and file size.

Transparent GIF only supports 1-bit alpha: a pixel is either fully visible or fully gone. On soft edges, shadows, glows, or anti-aliased text this produces ugly fringing, especially over colored backgrounds. Test the result on the intended background before using it for soft-edged artwork.

WebM and raster Lottie can preserve soft alpha when the encoder and player support it. Check the exported result on light and dark backgrounds; source quality and keying settings still affect hair, shadows, glows, and translucent edges.

There is no single smallest format for every clip. Export the same time range, dimensions, frame rate, and background settings, then compare actual bytes and playback. WebM alpha support is a separate question from ordinary WebM playback; test the exact file in each target browser, including Safari and mobile environments.

Lottie ZIP needs a player that supports image assets. Unpack the archive when required and preserve the paths between animation JSON and images. GIF needs no Lottie runtime but has a limited palette and binary transparency. A successful preview in one player is not a compatibility guarantee for every platform.

Match the format to the player you already have and the browsers you must support.