How to Convert a GIF to Animated WebP (and Cut File Size 50–90%)

Why bother converting at all

GIF carries three structural penalties that animated WebP simply does not. It is locked to a 256-color palette per frame, so any gradient or natural-color content bands and dithers. Its transparency is binary — a pixel is either fully opaque or fully gone — which leaves jagged edges on soft shadows and feathered logos. And its LZW compression encodes every frame independently, with no awareness of what stayed the same from one frame to the next.

Animated WebP fixes all three: 24-bit color, a full 8-bit alpha channel, and inter-frame prediction borrowed from video codecs. The practical upshot is a smaller, sharper file that plays in every modern browser. If you want the full head-to-head on color, alpha, and compression, read WebP vs GIF. This guide stays practical: you have a GIF, and you want it smaller.

The browser way (no install)

The fastest route is to drop the GIF straight into a browser converter. The 2WebP converter accepts GIF input directly — you do not need to convert to video first. Drag the file in, pick a quality level, and download the WebP. Everything runs locally via FFmpeg compiled to WebAssembly, so the file never leaves your machine. There is no upload, no queue, and no size cap imposed by a server.

Under the hood it runs the same libwebp encoder you would call from the command line, just wrapped in a UI that shows you the before/after size and lets you nudge the quality slider until the trade-off looks right. For a one-off conversion or anything you would rather not script, this is the path of least resistance.

If you are converting many GIFs in a build step, or want to wire this into a pipeline, the command line is the better fit. That is next.

The FFmpeg way (one command)

FFmpeg reads GIF natively and encodes WebP through libwebp. A lossy conversion at quality 75 is the sensible default for most content:

# Lossy animated WebP — good default
ffmpeg -i input.gif -vcodec libwebp -lossless 0 -q:v 75 -loop 0 output.webp

# Lossless variant — pixel-perfect, larger
ffmpeg -i input.gif -vcodec libwebp -lossless 1 -loop 0 output_lossless.webp

The flags, briefly:

• -vcodec libwebp selects the WebP encoder. Without it FFmpeg guesses from the extension, which can pick the wrong path for animation.
• -lossless 0 chooses lossy (VP8) coding; -lossless 1 switches to lossless (VP8L).
• -q:v 75 sets quality on a 0–100 scale. It only applies in lossy mode. Higher means better looking and bigger; 75 is a strong middle ground.
• -loop 0 loops the animation forever, matching the default GIF behavior. Any other number loops that many times.

You can add -compression_level 6 to spend more encoder effort for a slightly smaller file at the cost of encode time. For the full rundown of every libwebp flag — including -preset, filter chains, and frame-rate control — see the FFmpeg flags guide.

One thing GIF→WebP does not need: a palette pass. The two-pass palettegen/paletteuse dance is only for producing good GIFs. When the GIF is your source, you are decoding an existing palette and re-encoding into a full-color format, so a single command is all it takes.

What to expect on file size

Savings depend heavily on what the GIF contains. Google's published animated WebP comparison reports that, at matched visual quality, animated WebP averages roughly 64% smaller than the equivalent GIF across its test set. That average is a useful anchor, but your individual result will land somewhere on a wide band:

The pattern is intuitive once you know why GIF is inefficient. The format wastes the most bytes on content it was never built for — photographic gradients and natural motion — so that is exactly where WebP claws back the most. A GIF that is already a handful of flat colors is close to GIF's best case, so the conversion gain is smaller.

If you need to hit a specific byte budget rather than a quality target, lower -q:v in steps and re-check. The 2WebP converter does this search for you when you set a target size, binary-searching quality to land under the limit.

When not to convert

Smaller is not always the goal. The one place where converting actively hurts is email. Outlook on Windows renders HTML mail through Microsoft Word's engine, which has no WebP support, and a meaningful share of corporate inboxes still run those versions. A WebP in an email there shows up as a broken image. If your animation is destined for an inbox you do not control, keep the GIF — or read animated WebP for email for the fallback strategy.

The other case is tooling you cannot change. If a downstream system, CMS, or teammate's editor only handles GIF, the saved bytes are not worth a broken workflow. Everywhere else on the open web — pages, docs, blog embeds, social platforms that accept WebP — converting is the right call.

Gotchas worth knowing

A few things trip people up converting GIF to WebP:

• Transparency edges. GIF only stored a hard on/off mask, so the edges of a transparent GIF were already aliased before you started. Lossy WebP can add faint fringing around those hard edges. If transparency matters and you see artifacts, switch to -lossless 1 — lossless WebP preserves the alpha exactly and is still usually smaller than the GIF.
• Very long GIFs. A long, high-frame-rate GIF encodes to a large WebP too, and the in-browser WebAssembly encoder works harder on long clips. If the source is really a video that someone exported to GIF, you will get a far better result converting from the original video than from the lossy, palette-reduced GIF.
• Already-tiny GIFs.On very small files, WebP's container and per-frame overhead can dominate, and the converted file may be the same size or even slightly larger. Below a few kilobytes the conversion is rarely worth it — leave it as a GIF.
• Frame timing.FFmpeg generally preserves the GIF's per-frame delays, but some GIFs encode timings the WebP container rounds differently. If playback speed looks off, check the source frame rate before blaming the encoder.

The short version

For almost any GIF headed to a web page, convert it. Use lossy WebP at quality 75 as your default; reach for lossless when transparency must be exact. Expect roughly 50–70% smaller for video-sourced GIFs, less for flat-color graphics, and close to break-even for files that are already tiny. Skip the conversion only for email you do not control, GIF-only tooling, and GIFs small enough that overhead cancels the win.

If the source GIF was originally a video, going back to that video will always beat re-encoding the GIF — but when the GIF is all you have, a single FFmpeg command or one drag into the browser is all it takes.