Convert Animated WebP to MP4: FFmpeg 9 Finally Decodes It

You have a folder of animated WebP files and something downstream that only accepts MP4: a social posting API, a video editor, an ad platform. Every guide you find tells you to dump the frames with a separate libwebp tool and glue them back together. That advice was correct until August 2026.

Quick answer: Converting animated webp to mp4 takes one command on FFmpeg 9.0 or newer, which added a webp_anim demuxer: ffmpeg -i animation.webp -c:v libx264 -pix_fmt yuv420p out.mp4. On FFmpeg 8.1.2 and older the same command dies with Could not find codec parameters for stream 0 (Video: webp, none): unspecified size and decodes zero frames, which is why older guides dump PNG frames with libwebp's anim_dump and rebuild them with image2. If you can't ship FFmpeg 9 to your servers yet, send the file to a hosted FFmpeg API and get the MP4 back instead of upgrading your infrastructure.

Conventional wisdom says FFmpeg can't read animated WebP

Most FFmpeg builds in production today genuinely can't read animated WebP, so the advice isn't wrong, it's just dated. The cause isn't a missing codec. FFmpeg has shipped a libwebp encoder for years and can write animated WebP fine. What was missing was a demuxer that understood the ANMF chunk layout inside the RIFF container, so the file opened, the stream was identified as webp, and then the decoder had no dimensions and no frame count to work with. Zero frames out, one confusing error line.

FFmpeg 9.0 "Lei" shipped on 2026-08-03 and added that demuxer. The file now opens as a normal video stream with a width, a height, a frame count, and per-frame durations. No flags, no patches, no second tool.

Check what you actually have before you debug anything else:

ffmpeg -version | head -1
ffmpeg -demuxers | grep webp

On 9.0 or newer, webp_anim appears in that demuxer list. On 8.x it does not, and no combination of -f, -c:v libwebp, or -analyzeduration will make the decode work.

The old workaround costs you your frame timing

The pre-9.0 recipe runs anim_dump from libwebp to write every frame as a PNG, then rebuilds a video from the numbered sequence:

anim_dump -folder frames animation.webp
ffmpeg -framerate 25 -i frames/dump_%04d.png \
  -c:v libx264 -pix_fmt yuv420p out.mp4

That produces an MP4, and for a lot of files it looks right. What it throws away is the timing. Animated WebP stores a duration in milliseconds for every frame in its own ANMF chunk, and those durations do not have to be equal. anim_dump writes flat PNGs with no duration metadata, so -framerate 25 is you guessing. A sticker with a 500 ms hold on its last frame and 40 ms on everything else comes out of that pipeline with the hold gone.

You can see the real durations without decoding anything:

webpmux -info animation.webp

Each frame line includes its duration. If those numbers vary, the frame-dump workaround will change how the animation plays.

One command, plus the two arguments you actually need

On FFmpeg 9.0 the direct conversion is short, but two things are worth adding for anything that has to survive a real player. First, probe the file:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=width,height,nb_frames,r_frame_rate \
  -of csv=p=0 animation.webp

Animated WebP is frequently an odd size. Sticker exports at 498x498 are common, and VP8 allows any dimension up to 16383x16383, so nothing upstream forced an even number. H.264 with yuv420p requires both dimensions divisible by two, so the encode fails with height not divisible by 2 unless you round:

ffmpeg -i animation.webp \
  -vf "scale=trunc(iw/2)*2:trunc(ih/2)*2" \
  -c:v libx264 -preset veryfast -crf 20 \
  -pix_fmt yuv420p -movflags +faststart \
  out.mp4

-movflags +faststart moves the moov atom to the front so the file starts playing before it finishes downloading, which matters if the MP4 is going straight to a CDN or an upload endpoint. And no, you can't stream-copy your way out of the re-encode here: the source frames are VP8 key frames in a RIFF container, not H.264, so -c:v copy has nothing valid to copy into an MP4. The same rule that makes filtering and streamcopy mutually exclusive applies.

Transparent WebP goes black in MP4 unless you composite a background

H.264 in an MP4 has no alpha channel that any mainstream player honors, so a WebP with transparency encodes its transparent pixels as solid black. This is the single most common surprise when converting sticker and logo animations, and it is not a bug in the demuxer. Alpha is being discarded because the target format has nowhere to put it.

Composite the animation over a known background instead:

ffmpeg -i animation.webp \
  -filter_complex "color=c=white:s=498x498:r=25[bg];[bg][0:v]overlay=shortest=1,scale=trunc(iw/2)*2:trunc(ih/2)*2,format=yuv420p" \
  -c:v libx264 -crf 20 -movflags +faststart out.mp4

Set s= to the dimensions ffprobe reported and r= to the frame rate you want, because overlay takes its output rate from the first input. Use c=black or a hex value like c=0x0F1117 to match wherever the video will be embedded.

If you genuinely need the transparency preserved, MP4 is the wrong container. VP9 in WebM keeps alpha with -c:v libvpx-vp9 -pix_fmt yuva420p, and ProRes 4444 keeps it in a MOV for editorial handoff. Pick one of those when a designer needs the file, and the composited MP4 when a posting API needs it.

Variable delays, and the flag that disappeared in FFmpeg 9

Animated WebP is variable frame rate by nature, and MP4 playback is happiest at a constant rate, so you have to decide which one wins. Two choices, both explicit:

# Normalize to constant 30 fps (safest for posting APIs)
ffmpeg -i animation.webp -fps_mode cfr -r 30 \
  -c:v libx264 -pix_fmt yuv420p out.mp4

# Preserve original per-frame timestamps
ffmpeg -i animation.webp -fps_mode passthrough \
  -c:v libx264 -pix_fmt yuv420p out.mp4

-vsync was hard-removed in FFmpeg 9.0 along with -top, -qphist, -filter_complex_script, and -adrift_threshold. If you copy a -vsync vfr line out of an older post you'll get Unrecognized option 'vsync' from the same build that just gained WebP support, which is a confusing pair of symptoms to hit in one command. -fps_mode is the replacement and it has been available since 5.1, so it's safe in both directions. That removal is already breaking frame-extraction scripts in agent tooling repos, the same trap as extracting a last frame for clip chaining.

Common pitfalls

Most failures here come from the environment rather than the command, so check these before rewriting your filter graph.

When you can't put FFmpeg 9 in production yet

Plenty of teams can't. Your base image is pinned, FFmpeg 9 bumped every library major for a full ABI break, and validating that against the rest of your media pipeline is a sprint, not an afternoon. Meanwhile the WebP files keep arriving, because image CDNs auto-convert GIFs to animated WebP and scrapers save whatever the CDN served. One n8n builder hit this with roughly 400 product animations that a posting API rejected outright.

The mechanism that fixes that isn't a faster upgrade, it's not owning the binary. FFmpeg Micro runs a managed FFmpeg build, so the same conversion is one API call from code, from n8n, Make, or Zapier, or from an AI agent over MCP, with no encoder to install and no version to pin. You can paste the exact arguments above into the playground and watch the MP4 come back before you write any integration code. The free tier covers testing a batch.

Local FFmpeg is still the right answer when you already run 9.0, the files are small, and the work fits in your own process. Offloading earns its keep when the volume is bursty, the inputs are untrusted, or upgrading the binary is the part you can't schedule.

FAQ

Can FFmpeg convert animated WebP to MP4 without any other tools?

FFmpeg converts animated WebP to MP4 on its own starting with version 9.0, released 2026-08-03, using the new webp_anim demuxer. On FFmpeg 8.1.2 and earlier you need libwebp's anim_dump to extract PNG frames first, because those builds decode zero frames from an animated WebP.

Why does my converted WebP have a black background?

A converted WebP has a black background because H.264 inside an MP4 carries no alpha channel, so transparent pixels become solid black. Composite the animation over a color source with the overlay filter, or encode to VP9 in WebM with -pix_fmt yuva420p if the transparency has to survive.

What FFmpeg version added animated WebP decoding?

FFmpeg 9.0 "Lei" added animated WebP decoding via a webp_anim demuxer. The 9.0.1 patch followed on 2026-08-12 and 9.0.2 on 2026-09-18, the latter carrying H.264 and MOV demuxer memory-safety fixes worth having if you decode files uploaded by other people.

Does converting animated WebP to MP4 lose quality?

Converting animated WebP to MP4 is lossy twice over: the WebP frames were already VP8-compressed, and re-encoding them to H.264 adds a second generation. Use -crf 18 to -crf 20 for short animations where file size barely matters, and skip any temptation to downscale before you know the target dimensions.

Can I go the other direction and make animated WebP from a video?

FFmpeg has written animated WebP for years through the libwebp encoder, no version 9 required. That direction is covered in converting video to animated WebP, including why the output lands around a tenth the size of the equivalent GIF.

If your WebP pile is bigger than your patience for a base-image upgrade, run one file through the playground with the composite filter above, then sign up free and point the same call at the rest of the batch.