FFmpeg command line versus this browser compressor

If you already have FFmpeg installed, you mostly do not need this. That is the honest summary, and the rest of this page is about the specific cases where it is wrong — plus the commands this tool is equivalent to, so you can skip it entirely if you would rather.

Drop your video here

or click to browse — MP4, MKV, MOV, WebM, AVI and more

This is FFmpeg, with less of it

There is no reimplementation involved. FFmpeg is compiled to WebAssembly and runs inside the page, so the same decoders and the same x264, x265 and libvpx encoders are doing the work. When you press the button, the tool assembles an argument list and executes it, and that argument list is printed in the log panel before the encode starts.

What is missing is scope. The browser build carries a subset of the encoders: H.264, H.265, VP9 and MPEG-4 for video, AAC and Opus for audio, with no AV1 and none of the hardware acceleration a native build can reach. It also has to use fast presets, because a browser tab that takes forty minutes on a two-minute clip is not a usable tool. That preset pressure falls hardest on H.265 and VP9, which are slow enough in WebAssembly that a native run is worth walking to the terminal for. Same engine, deliberately narrowed.

The commands this replaces

If you have FFmpeg, these are the recipes that cover almost everything this site does. They are worth knowing regardless — the tool is building the same arguments.

Compress with constant quality

ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k output.mp4

CRF is the setting you actually want most of the time. Lower is better quality and a larger file; 18 is close to visually lossless, 23 is a sensible default, 28 is visibly compressed. The file size is whatever it turns out to be.

Hit a specific file size with two passes

ffmpeg -y -i input.mp4 -c:v libx264 -b:v 2400k -pass 1 -an -f null /dev/null
ffmpeg -i input.mp4 -c:v libx264 -b:v 2400k -pass 2 -c:a aac -b:a 128k output.mp4

Work out the bitrate first: target megabytes × 8 × 1024 ÷ duration in seconds, minus the audio bitrate. The first pass analyses the video and writes a log; the second uses it to distribute bits intelligently. This is what target-size mode here approximates with a measure-and-correct loop.

Downscale to 720p

ffmpeg -i input.mp4 -vf scale=-2:720 -c:v libx264 -crf 23 -c:a copy output.mp4

The -2 keeps the aspect ratio and rounds the width to an even number, which H.264 requires. Almost always a bigger saving than any bitrate change.

Encode H.265 or VP9 instead of H.264

ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium -tag:v hvc1 -c:a aac -b:a 128k output.mp4
ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 33 -b:v 0 -row-mt 1 -c:a libopus -b:a 128k output.webm

Both codecs are in the browser build too, but natively they finish in a fraction of the time and you can afford a slow preset, which is where most of their advantage actually lives. The hvc1 tag is not optional if you want QuickTime or Safari to open the MP4. Note the CRF numbers are not comparable across the three encoders.

Change the container without re-encoding

ffmpeg -i input.mkv -c copy output.mp4

No decoding, no encoding — the streams are copied into a new wrapper. Finishes in seconds on a file of any length and loses nothing. Only works if the codecs inside are legal in the destination container.

Strip the audio

ffmpeg -i input.mp4 -an -c:v copy output.mp4

Worth knowing when a size budget is tight. On a long low-bitrate clip the audio track stops being a rounding error.

Where the command line wins

  • Speed. Native code, all your cores properly, and optional hardware encoders. On a long file it is not close.
  • Two-pass rate control. A genuine first analysis pass distributes bits across the whole timeline far better than any single-pass approximation, including the corrective loop used here.
  • Every codec, at full speed. AV1, ProRes, FLAC, whatever your build has. x265 and VP9 exist in the browser build, but a native run of either finishes in a fraction of the time.
  • Filters and stream mapping. Crop, denoise, deinterlace, burn in subtitles, keep six audio tracks, concatenate. None of that exists here. Trimming does — set a start and an end point, and in Remux mode the cut is made without re-encoding — but it is one range, not an edit list.
  • Scripting. A shell loop over three hundred files, in a Makefile, in CI. This tool does one file at a time by hand.
  • No memory ceiling. FFmpeg streams through a file. A browser tab holds the whole thing in memory and eventually runs out.

Where the browser wins

  • Nothing to install. On a locked-down work machine, a lab computer or a Chromebook, "install FFmpeg" is not an available step.
  • It works on a phone. There is no comfortable FFmpeg story on iOS.
  • You can give it to someone else. This is the real one. Sending a colleague a link they drag a file onto costs them nothing; sending them a command costs you the next twenty minutes of support.
  • Immediate feedback on size. The tool shows the solved bitrate before it encodes, then the before and after sizes when it finishes. Getting the same loop on the command line means running it and checking with ls -lh each time.

On CRF versus a size target

The difference between these two is worth internalising, because it explains most of the settings on this site. CRF asks for a quality level and lets the size fall where it falls: easy scenes get few bits, hard scenes get many, and the picture stays consistent throughout. It is the right mode whenever you do not have a hard limit.

Bitrate targeting asks for a size and lets the quality fall where it falls. It is the right mode when something will reject your file above a number, and the wrong mode the rest of the time. That is why target-size mode exists here alongside the quality slider rather than replacing it. The bitrate guide works through CBR, VBR and CRF properly.

Questions

Is this the same FFmpeg?

It is FFmpeg compiled to WebAssembly, so it is the same codebase and the same encoders, running inside a browser sandbox rather than as a native binary. The build carries a subset of the encoders and runs slower than native code, but the commands it constructs are ordinary FFmpeg commands — you can see them in the log panel while it works.

Which is faster, FFmpeg on the command line or in the browser?

The command line, substantially. WebAssembly executes at a fraction of native speed, has no access to hardware encoders, and here uses fast presets to stay usable. If you already have FFmpeg installed and the file is large, use it.

What FFmpeg command does this tool run?

Whatever your settings build. Expand the log panel during a compression and the full argument list is printed before the encode starts, so you can copy it and run the same job natively if you would rather.

Why would I use a browser version if I have FFmpeg installed?

Mostly you would not. The cases where it wins are a machine where you cannot install anything, a phone, and handing the job to someone who does not use a terminal — a link they can drag a file onto is a very different ask from a command they have to get right.

Related