How to Convert Video to Animated WebP (and Why)

Why animated WebP instead of GIF or MP4

The format question comes down to context. If you need animation that plays without a video tag — inside a Markdown README, an HTML email, or a CMS image field — your choices narrow quickly. MP4 needs a <video> element with the autoplay and muted attributes, and even then, iOS Safari has historically blocked autoplay in certain contexts. Where MP4 is allowed and the context supports a video element, use it — H.264 compression is hard to beat on file size for long clips.

GIF works everywhere an image tag is accepted, but it carries serious penalties: a 256-color palette per frame, binary transparency (hard edges only), and LZW compression that works frame-by-frame rather than exploiting inter-frame similarity. A 5-second 640px clip routinely exceeds 3 MB as a GIF. The same clip as animated WebP at quality 75 typically lands under 1 MB with visibly better color. For the full comparison, see the WebP vs GIF breakdown.

Animated WebP fills the gap: it works in any <img> tag, supports 24-bit color and 8-bit alpha, and delivers lossy or lossless compression with inter-frame prediction. Browser support sits around 97% globally as of 2026-05. The cases where you still need GIF — legacy Outlook clients, niche embedded browsers — are narrow and shrinking. For everything else on the web, animated WebP is the right choice. If you want to compare it against video specifically, the WebP vs MP4 guide covers the tradeoffs in detail.

The shape of a good source clip

Not all source footage converts equally well. Before you run anything through ffmpeg or the browser tool, it helps to know what makes a clip a good candidate.

Length: For loops — product animations, UI demos, loading states — 3 to 8 seconds is the right range. Shorter clips loop more naturally and stay small. Product demos and tutorial snippets can go up to about 15 seconds before the file size starts becoming a real problem at normal quality settings. Beyond 15 seconds, seriously consider a video element instead.

Resolution:Match the output resolution to where you're displaying the image. Don't upscale — it adds file size without adding quality. Downscaling is fine and often necessary; ffmpeg's Lanczos filter (flags=lanczos) gives the sharpest results when scaling down.

Codec: H.264, H.265, and VP9 sources all decode correctly via ffmpeg. The source codec only affects decode speed at the start of the pipeline — it has no bearing on the output WebP quality. Older DV or MJPEG sources also work, just slower.

Frame rate: A 24–30 fps source is ideal. If your source is 60 fps, ffmpeg will encode all those frames unless you tell it not to, which produces a noticeably larger file for minimal perceptual benefit. Use a fps filter to bring it down to 24 before the WebP encoder sees it. The exception is slow-motion or stutter-effect content where the high frame rate is intentional — in that case, keep it and accept the size.

Trimming and choosing in/out points

Trim before you encode. Sending the full source file through the WebP encoder means it has to decode every frame, including everything you plan to cut. It also means the audio stream (which WebP cannot carry anyway) has to be demuxed during encode. Trim first and you get a faster encode and a cleaner pipeline.

The ffmpeg trim command uses -ss for the start and -to for the end. When -ss appears before -i(input-side seek), ffmpeg seeks to the nearest keyframe before decoding — very fast, but the actual cut may land a few frames before or after the exact timestamp. That's fine for most use cases:

# Input-side seek (fast, keyframe-aligned — good enough for most trims)
ffmpeg -ss 00:00:02.5 -to 00:00:07.0 -i source.mp4 -c copy trimmed.mp4

If you need frame-accurate cuts — say, a loop that has to land exactly on a specific frame — move -ss to after -i (output-side seek). This forces ffmpeg to decode every frame up to the start point, which is slow for long files but precise:

# Output-side seek (slow, frame-accurate — use when loop timing matters)
ffmpeg -i source.mp4 -ss 00:00:02.5 -to 00:00:07.0 -c copy trimmed.mp4

The -c copyflag tells ffmpeg to copy the stream without re-encoding during the trim — it's near-instant and lossless. Save the re-encoding for the WebP conversion step.

FPS: 24 vs 30 vs 12 — what each costs

Frame rate is one of the biggest levers on animated WebP file size, and it's one most people don't adjust. Every additional frame is more data for the encoder to compress, even with inter-frame prediction. The relationship is roughly linear: halving the frame rate halves the frame count, which typically cuts file size by 40–55% depending on content complexity.

To set the output frame rate, use the fps video filter:

# Re-encode at 12 fps — useful for UI animations, email, small thumbnails
ffmpeg -i trimmed.mp4 -vf "fps=12,scale=480:-1" -c:v libwebp -quality 75 -loop 0 output.webp

In practice, here is how the three common choices behave:

24 fps is the right floor for anything that should feel like smooth video. Below that, motion starts to stutter noticeably on fast-moving content. 12 fps works well for UI demonstrations where the motion is deliberate and slow. 60 fps animated WebP is almost never worth it — the perceptual improvement over 30 fps for looped web animations is negligible, and the file size penalty is real.

Quality settings: lossless when, lossy when

The optimal settings guide covers this in depth, but here is the short version for video sources.

Lossy at quality 75 is the right default for most video-to-WebP conversions. Natural footage — skin tones, outdoor scenes, gradients, motion blur — encodes efficiently with lossy compression and the artifacts at q=75 are nearly invisible in motion. This is what 2WebP uses as its default.

Losslessmakes sense for flat-color animations, icon animations, and anything with sharp edges or transparency where lossy artifacts would be obvious. Lossless WebP is still meaningfully smaller than GIF on these assets, and pixel-perfect output matters when you're animating a logo.

Lossy at quality 50 is where you go when file size is the hard constraint — email campaigns with attachment limits, pages targeting very slow connections. Artifacts are visible on close inspection but acceptable for thumbnail-style uses. Below q=50, quality degrades noticeably and the savings rarely justify it for video sources.

The alpha-channel gotcha

This trips up a lot of people: most video codecs drop the alpha channel entirely. H.264, H.265, and standard VP9 all encode RGB only — there is no alpha track. If you convert an H.264 source to animated WebP expecting transparent areas, you will get a fully opaque WebP. The alpha is gone before ffmpeg even sees the input.

If your source is opaque — a screen recording, a standard camera clip, a product video — this is not a problem. You were never going to have alpha to begin with.

If you need transparent output, your source has to carry alpha. The formats that do:

• PNG image sequence — the most reliable option. Export frames as PNGs from your compositor (After Effects, DaVinci Resolve) and assemble with ffmpeg.
• ProRes 4444— Apple's production codec that carries a dedicated alpha channel. Standard in motion graphics workflows on macOS.
• VP8/VP9 with alpha in a WebM container — supported by ffmpeg and Chromium-based tools. Less common as a deliverable but works as an intermediate format.

When your source does carry alpha, the ffmpeg flag -c:v libwebp honors it automatically — no extra flags required. The alpha channel is preserved in the output WebP as a separate VP8L-encoded plane, as described in the ffmpeg formats documentation.

Audio doesn't survive the trip

WebP is an image format. There is no audio track — not encoded at low quality, not silently dropped and recoverable, just absent. ffmpeg will silently discard any audio stream when you encode to WebP.

This surprises people who convert a clip that relies on audio — a voiceover walkthrough, a product video with music, a tutorial. The visual output looks correct, so the conversion seems to work, and then someone notices the silence. If your clip communicates something through audio, animated WebP is not the right format for it. Use a <video> element with MP4/WebM, or host it on a platform that handles audio properly.

If you know you're working with a muted clip — a screen recording, a silent product loop — you're fine. Just know going in that anything in the audio track is gone on the other side.

Doing it in 2WebP vs. doing it in ffmpeg

Both approaches use the same underlying encoder (libwebp), so the output quality is equivalent given the same settings. The choice comes down to your workflow.

Use 2WebPwhen you have a one-off conversion and don't want to install anything. The conversion runs entirely in your browser via ffmpeg compiled to WebAssembly — your file never touches a server. That matters for footage that is confidential or not yet public. You get trim controls, a quality slider, and an fps picker without touching a terminal. Try it at /convert.

Use ffmpeg directly when you are processing multiple files, running from a CI pipeline, or want to script conversions as part of a build step. A shell loop over a directory of clips is a few lines. ffmpeg also gives you access to flags that no browser UI exposes — compression level, method, exact filter graphs.

The canonical ffmpeg one-liner for video to animated WebP:

ffmpeg -i input.mp4 -vf "fps=24,scale=480:-1" -c:v libwebp -loop 0 -quality 75 -compression_level 6 output.webp

Breaking it down:

• fps=24 — output frame rate. Adjust to 12 for smaller files, 30 for smooth screen recordings.
• scale=480:-1 — scale width to 480px, height auto-calculated to preserve aspect ratio.
• -c:v libwebp — use the libwebp encoder.
• -loop 0— loop infinitely (WebP's loop count, 0 = infinite).
• -quality 75 — lossy quality, 0–100. 75 is a good default for video sources.
• -compression_level 6 — encoder effort, 0–6. Higher means smaller file at the cost of encode time. 6 is max and reasonable for offline use.

For lossless output (icons, flat graphics, transparency):

ffmpeg -i input.mp4 -vf "fps=24,scale=480:-1" -c:v libwebp -lossless 1 -loop 0 -compression_level 6 output.webp