How to convert video to animated webp — smaller than the same gif
- Step 1Trim to the exact loop first (optional but recommended) — WebP size scales directly with frame count, so cut dead air before converting. Use lossless-trimmer to stream-copy a tight clip with no re-encode, then bring that trimmed file here. A 2-second loop is roughly half the bytes of a 4-second one at the same FPS and quality.
- Step 2Drop the clip onto the converter — The picker accepts
video/*plus.mp4,.mov,.mkv,.webm,.avi,.m4v, and.ts. FFmpeg.wasm decodes the source in your browser — nothing uploads. One file per run on this tool (it does not batch). - Step 3Set FPS for the size you're targeting — FPS accepts 5–60 (default 24). For a GIF replacement, 15–24 is the sweet spot: most GIFs were already 10–15 FPS, so dropping from a 30/60 FPS source to 15 FPS roughly halves the frame count and the file size with no visible jerkiness on a short loop.
- Step 4Set Width to your display size — Width accepts 120–1920 px (default 480). Height is computed automatically from the source aspect ratio (
scale=W:-1), so you never set it. Encode at the size it will actually display — a 480px loop shown at 240px wastes half its bytes. There is no upscaling benefit; pick a width at or below the source width. - Step 5Pick a Quality value (1–100) — Quality maps to libwebp's
-q:v. Default 80 is the GIF-replacement sweet spot. Drop to 60–70 for chat-grade loops where size wins; push to 90–95 for product or brand footage. Note: this is lossy WebP — even 100 is high-quality lossy, not true lossless (the encoder has no lossless toggle exposed). - Step 6Run, then size-check against the original GIF — Click Run; FFmpeg.wasm encodes the looping
.webpand hands it straight back for download. Compare the byte size to your old GIF. If it isn't smaller, the source was likely already low-colour line-art (where GIF's palette is efficient) — see the cookbook for when WebP loses.
WebP encode controls (what each one actually does)
The three controls exposed in the WebP options panel, with their real ranges from the client component and the FFmpeg argument each maps to. There is no height, loop-count, alpha, or lossless control.
| Control | Range / default | FFmpeg mapping | Effect on file size |
|---|---|---|---|
| FPS | 5–60 · default 24 | -vf fps=N | Roughly linear — halving FPS roughly halves the frame count and the bytes |
| Width (px) | 120–1920 · default 480 | scale=W:-1:flags=lanczos | Roughly quadratic — height auto-scales with width, so doubling width ~4× the pixel area |
| Quality | 1–100 · default 80 | -q:v N | Lossy VP8 quality; lower = blockier + smaller. 100 is high-quality lossy, not lossless |
| Loop (not a control) | Fixed -loop 0 | infinite loop, hardcoded | No effect — every export loops forever; there is no loop-count field |
| Audio (not a control) | Always dropped | -an | WebP has no audio; the source track is discarded regardless |
Animated WebP vs animated GIF for the same loop
Why WebP wins on photographic footage and where GIF can still tie. Sizes are representative for a ~3s clip and vary with content.
| Property | Animated WebP (this tool) | Animated GIF ([video-to-gif](/video-tools/video-to-gif)) |
|---|---|---|
| Colour depth | Full 16.7M colour (24-bit) | 256-colour palette per frame |
| Typical size (photo footage) | Baseline — usually 25–35% smaller | Heaviest — palette + dithering overhead |
| Gradients / skin tones | Clean, no speckle | Visible dithering / banding |
| Encode method here | Single-pass libwebp -q:v | Two-pass palettegen + paletteuse |
| Best for | Modern web, Telegram, Signal, Discord | Email, ancient surfaces, flat line-art with few colours |
Cookbook
Real GIF-to-WebP swaps with the controls that produced them. Sizes are representative — your mileage depends on motion and colour complexity.
Heavy product GIF → WebP at default settings
A 3-second 480px product loop exported from another tool as a 5.2 MB GIF. Re-encoding the source clip to WebP at the defaults (24 FPS, 480px, quality 80) keeps the colour fidelity and cuts the bytes.
Source: product-demo.mp4 (3.0s, 1080p, 30fps) Controls: FPS 24 · Width 480 · Quality 80 FFmpeg (libwebp): -vf fps=24,scale=480:-1:flags=lanczos -loop 0 -q:v 80 -an Result: old GIF 5.2 MB (256-colour, dithered) new WebP 1.9 MB (full colour, clean gradient) → ~63% smaller, no visible quality loss
Drop FPS to halve the size of a long-ish loop
A 6-second screen-capture loop is too heavy at 24 FPS. Screen recordings move slowly, so 12 FPS is invisible to the eye and roughly halves the frame count.
Source: ui-walkthrough.mov (6.0s) A) FPS 24 · Width 720 · Quality 80 → 4.1 MB B) FPS 12 · Width 720 · Quality 80 → 2.2 MB Half the frames, same width/quality → ~half the bytes. For slow UI motion the lower FPS is imperceptible.
Width is the biggest lever (it scales area, not length)
Same clip, same FPS and quality, only width changes. Because height auto-scales with width, halving the width cuts the pixel area to a quarter.
Source: loop.mp4 (3.0s, 24fps, q80) Width 960 → 3.4 MB Width 480 → 0.95 MB (≈ 1/4 area, ≈ 1/3.5 bytes) Width 240 → 0.30 MB Encode at display size. A 960px WebP shown in a 300px slot is paying for pixels nobody sees.
When GIF actually ties (or wins): flat line-art
A 4-colour logo wiggle is exactly the case GIF's palette was built for. WebP's full-colour machinery has nothing to exploit, so the gap closes. WebP still usually edges it out, but don't expect the dramatic photo-footage win.
Source: logo-bounce.mov (2.0s, 4 flat colours) GIF (256-palette) 180 KB WebP (FPS 24, q80, 480px) 165 KB → Only ~8% smaller. The WebP advantage is largest on photographic/gradient content, smallest on flat graphics.
Quality dial for a chat-grade reaction loop
A throwaway reaction clip for a group chat doesn't need brand fidelity. Dropping quality to 60 trims bytes hard while staying perfectly watchable at small size.
Source: reaction.mp4 (2.0s, 24fps, 320px) Quality 90 → 480 KB Quality 80 → 310 KB (default) Quality 60 → 180 KB (chat-grade, fine at small size) Lower quality shows first on hard edges and text — keep 80+ if the loop contains captions or a logo.
Edge cases and what actually happens
Output WebP is not smaller than the source GIF
By designWebP's size advantage comes from full-colour inter-frame coding. On flat, low-colour line-art (a logo wiggle, a 4-colour icon), GIF's 256-palette is already efficient and the gap collapses to single digits — sometimes WebP is only marginally smaller or roughly tied. This is expected, not a bug. The big wins are on photographic footage, gradients, and live-action.
Audio track silently disappears
By designAnimated WebP is an image container — it has no audio channel. The encoder runs with -an, so any audio in the source is dropped. This is correct for a loop, but if you actually needed sound, WebP is the wrong target: keep the clip as MP4 via video-transcoder or compress it for a chat app with discord-compressor.
Source has no alpha, so the WebP has no transparency
Expectedlibwebp preserves an alpha channel only if the source frames carry one — and ordinary camera/screen video does not. Converting an opaque MP4 produces an opaque WebP. There is no add-transparency control here; transparency requires a source (e.g. a ProRes 4444 or VP9-alpha clip) that already has an alpha channel.
You wanted true lossless WebP
Not exposedThe encoder uses lossy VP8 (-q:v). Even Quality 100 is high-quality lossy, not the -lossless 1 mode — that toggle is not exposed in the UI. For a short loop the lossy path at 90–95 is visually indistinguishable and far smaller, so this rarely matters; if you genuinely need pixel-exact frames, WebP animation is not the right format.
Asking for a single loop count instead of infinite
Not configurableLoop count is hardcoded to -loop 0 (infinite). There is no field to make the WebP play once and stop. Every export from this tool loops forever wherever animated WebP renders. If you need play-once behaviour, that is a player/CSS decision on the page, not an encoder setting.
Setting Width above the source resolution
No benefitWidth accepts up to 1920, but upscaling past the source width only invents pixels and inflates the file — it adds no detail. Lanczos scaling sharpens downscales nicely; upscales just get bigger and softer. Pick a width at or below the source's native width.
Very long clip produces a huge WebP
Trim firstWebP size grows with total frame count (duration × FPS). A 30-second clip at 24 FPS is 720 frames and can balloon to tens of MB. Animated WebP is meant for short loops — trim to the essential seconds with lossless-trimmer before converting, or drop the FPS substantially.
File exceeds your tier's size limit
413 tier limitVideo tools are gated by file size, not duration. Free allows 1 GB / 1 file; Pro 10 GB / 5 files; Pro-media 100 GB / 50 files; Developer 100 GB / unlimited files. A raw source over your cap is rejected before encoding — trim or downscale the source, or upgrade. There is no minutes cap, only bytes and batch count.
Unusual or corrupt input container fails to decode
WebP encode failedThe picker accepts mp4, mov, mkv, webm, avi, m4v, and ts; an extension outside that set is treated as mp4 on read, which can fail if it isn't actually MP4. If FFmpeg.wasm can't decode the stream you'll see a 'WebP encode failed' error with the FFmpeg log tail. Re-wrap the source to a clean MP4 with video-transcoder and retry.
Frequently asked questions
How much smaller is animated WebP than GIF, really?
For photographic or live-action footage, typically 25–35% smaller at equivalent visual quality, and often more — a heavily-dithered GIF can be 50–60% larger than its WebP equivalent. The advantage comes from libwebp's VP8 inter-frame prediction and full-colour coding versus GIF's per-frame 256-colour palette. For flat, few-colour line-art the gap narrows to single digits because GIF's palette is already efficient there.
What controls do I actually get?
Three: FPS (5–60, default 24), Width in px (120–1920, default 480, height auto-locked to the source aspect ratio), and Quality (1–100, default 80). There is no height field, no loop-count field, no alpha toggle, and no lossless toggle — loop is always infinite and audio is always dropped.
Does the converter set the height too?
No — and you don't want it to. You set Width only; height is computed automatically from the source aspect ratio via scale=W:-1:flags=lanczos. That guarantees the loop never gets squashed or stretched, and Lanczos keeps downscales sharp.
Will the WebP loop forever or play once?
Forever. The encoder hardcodes -loop 0 (infinite loop), and there is no field to change that. Wherever animated WebP renders — modern browsers, Telegram, Signal, Discord — it autoplays and repeats. Play-once is a player/CSS choice on your page, not something the encoder controls.
Why did my audio disappear?
Animated WebP is an image format with no audio channel, so the encoder runs with -an and drops the source audio. That's correct for a silent loop. If you needed sound, WebP is the wrong target — keep the clip as MP4 (transcode or size-compress it instead).
Can I get a transparent (alpha) animated WebP?
Only if your source already has an alpha channel. libwebp preserves transparency it's given, but ordinary camera and screen recordings are opaque, so the output is opaque. There's no control here to add transparency — that needs a source like ProRes 4444 or VP9-with-alpha.
Is the output truly lossless if I set Quality to 100?
No. The encoder uses lossy VP8 (-q:v); Quality 100 is high-quality lossy, not libwebp's separate -lossless 1 mode, which isn't exposed. For a short loop, 90–95 lossy is visually indistinguishable and far smaller, so the distinction rarely matters in practice.
What input formats can I drop in?
video/* plus .mp4, .mov, .mkv, .webm, .avi, .m4v, and .ts. Anything with an unrecognised extension is read as MP4, which may fail if it isn't really MP4. If decode fails, re-wrap the source to a clean MP4 first.
Does my video get uploaded?
No. Encoding runs entirely in your browser via FFmpeg.wasm — the source clip never reaches a server. That's why even an unreleased product clip is safe to convert here. The only thing recorded server-side (if you're signed in) is an anonymous processed-file counter, no content.
How big a file can I convert?
Video tools are gated by file size, not duration. Free is 1 GB / 1 file; Pro 10 GB / 5 files; Pro-media 100 GB / 50 files; Developer 100 GB / unlimited files. There's no minutes limit — but remember WebP is for short loops, so trim long sources first regardless of tier.
Should I use this or video-to-gif?
Use WebP for modern destinations — websites, Telegram, Signal, Discord — where it's smaller and cleaner. Use video-to-gif only when the destination genuinely can't render WebP (email clients, some legacy CMSes). For a still preview frame instead of a loop, use thumbnail-extractor.
My WebP came out bigger than expected — what happened?
Almost always too many frames (long duration × high FPS) or too large a width. Width scales the file roughly with area, so it's the biggest lever — drop it to display size first, then lower FPS, then quality. Trimming the clip to the essential loop with lossless-trimmer is the single most effective fix.
Privacy first
Every JAD Video tool runs entirely in your browser via WebCodecs and FFmpeg (WebAssembly). Your video files never leave your device — verified by zero outbound network requests during processing.