FFmpeg recipe

FFmpeg: Convert MP4 to WebM (VP9 + Opus)

WebM is 20–40% smaller than MP4 at equal visual quality, and royalty-free. Browser-friendly, no licensing concerns.

Command

ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 33 -b:v 0 -c:a libopus -b:a 128k -y output.webm

Prefer no terminal?

Use the Video Converter in your browser

-i	Input file. Can be a video, audio, or image. Repeat for multiple inputs.
-c:v	Video codec for output. e.g. libx264, libx265, libvpx-vp9.
-crf	Constant Rate Factor — quality target (lower = better, larger file). 23 is visually lossless for libx264.
-c:a	Audio codec for output. e.g. aac, libmp3lame, copy.
-b:a	Audio bitrate, e.g. 192k.
-b:v 0	Tells VP9 to use pure CRF mode (no target bitrate cap). Standard for quality-first encoding.

VP9 encoding is slow — roughly 5x real-time on a modern CPU.
For two-pass encoding (sharper at low bitrates), use -pass 1 then -pass 2 with the same -b:v target.

ffprobe -v error -show_entries stream=codec_name -of csv=p=0 output.webm

vp9 and opus. Anything else means the codec flags did not apply.

-crf behaves differently in VP9	The scale is not H.264's. 30-35 is the useful range, and you need -b:v 0 alongside it or the CRF is ignored.
-row-mt 1 and -cpu-used	VP9 is slow. Row multithreading and a higher cpu-used cut the encode time a long way at a small size cost.
Consider AV1 instead	If the target supports it, libaom or SVT-AV1 is smaller again. It is slower still to encode.

The encode takes many times longer than an MP4 conversion.

Why: VP9 is far more expensive to encode than H.264, and by default it runs on a single thread for much of the work.

Fix: Add -row-mt 1 and -threads 8 to use more cores, or -deadline good -cpu-used 2 to trade a little size for speed.

The file is larger than the MP4 it came from.

Why: A bitrate was set instead of a quality target, or -b:v was left at a default that does not suit the content.

Fix: Use constant quality: -b:v 0 together with -crf, which is what makes VP9 smaller than H.264 at matching quality.