HandBrake vs FFmpeg: Same Engines, Different Jobs

I build VidClip on FFmpeg compiled to WebAssembly, so I spend a lot of time reading FFmpeg arguments and comparing what they produce against what people get out of HandBrake. The question comes up constantly, usually framed as "which one is better". That framing is the reason most answers to it are unhelpful. They are two front doors to largely the same machinery, and the useful question is which door fits the job in front of you.

Does HandBrake use FFmpeg under the hood?

Yes, in part, and the details matter. HandBrake's own documentation on supported source formats says it uses FFmpeg's libavformat and libavcodec libraries under the hood and can generally open whatever FFmpeg will open, plus disc-based sources such as DVD and Blu-ray. A HandBrake maintainer answering the same question on the project's GitHub put it more precisely: HandBrake uses parts of the FFmpeg libraries (libavformat, libavcodec, libavfilter), but it is not a GUI over the FFmpeg command line.

That second half is where the "HandBrake is just a GUI for FFmpeg" idea goes wrong. HandBrake does not build an ffmpeg command and run it behind the scenes. It links the libraries directly and wraps them in its own pipeline: its own scan of the source, its own filter chain, its own muxing logic and its own preset system.

The encoders are the other shared piece. HandBrake's list of video encoders names x264 for software H.264, x265 for software H.265, SVT-AV1 for AV1 and libvpx for VP8 and VP9, plus hardware encoders from Intel, AMD and Nvidia. FFmpeg's codec documentation describes its libx264 encoder as an "x264 H.264/MPEG-4 AVC encoder wrapper", and libx265 the same way for x265. So when you compare an H.264 file from each, you are usually comparing two sets of x264 settings, not two different encoders.

Here is the relationship at a glance:

Layer	HandBrake	FFmpeg command line
Reading files (demuxing)	FFmpeg's libavformat, plus its own disc reader	libavformat
Decoding	FFmpeg's libavcodec	libavcodec
Filters	Its own filters plus parts of libavfilter	libavfilter, the full set
H.264 / H.265 encoding	x264 / x265	x264 / x265 via libx264 / libx265
Settings	Presets, tuned per device and use	Encoder defaults unless you set them
Interface	Desktop app, plus a separate command-line build	Command line only

Why can the same settings give different files?

Because "the same settings" is almost never the same settings. When someone sets RF 22 in HandBrake and -crf 22 in FFmpeg, the quality target matches, but a dozen other decisions do not.

The most common sources of the gap:

• Presets set more than quality. A HandBrake preset decides the output resolution, the frame rate mode, audio codec and bitrate, the encoder preset and profile, and a handful of x264 or x265 options. An FFmpeg command sets only what you type, and everything else falls back to the encoder's defaults.
• Keyframe interval. x264 and x265 have fixed default keyframe intervals. HandBrake tends to choose its own, based on the frame rate of the source. A well-known Super User thread about x265 traced "visibly but not drastically" better output from HandBrake to exactly this kind of difference: FFmpeg left the encoder's defaults in place while HandBrake tuned the keyframe settings.
• Resolution and cropping. HandBrake presets cap the output size (the default preset is called Fast 1080p30 for a reason), and its crop setting has an automatic mode that trims black borders it detects. A file that got silently smaller in pixels also gets smaller in bytes.
• Frame rate. A preset that outputs 30 fps from a 60 fps phone clip throws away half the frames. That alone changes both size and motion.
• Audio. Different audio encoders and bitrates can shift file size by a few megabytes on a long clip, and people rarely compare the audio settings when they compare the video.

The practical lesson is that "HandBrake made a smaller file" or "FFmpeg looked worse" is usually a statement about defaults, not engines. If you copy HandBrake's full settings from its activity log into an FFmpeg command, you get very close to the same file. If you do not, FFmpeg's plain defaults, which are simply the encoder's own, are a reasonable starting point but not a tuned one. For how quality settings translate into actual megabytes, video compression by the numbers walks through the maths.

What can FFmpeg do that HandBrake can't?

HandBrake's about page is refreshingly direct about its limits. It lists, among the things it does not do, combining multiple video clips into one, creating discs, and passing video through without conversion, with the note that video is always converted.

That last one is the big difference for everyday work. FFmpeg's stream copy (-c copy) moves the compressed video into a new file without decoding or encoding it. The ffmpeg documentation spells out the trade: because there is no decoding or encoding, stream copy is very fast and there is no quality loss, but filters are impossible because they work on decoded frames. That gives you:

• Lossless trims. Cut the first minute off a two-hour recording in seconds, with no generation loss. The catch is that stream-copy cuts start on a keyframe, which I explain in lossless video trimming and keyframes.
• Remuxing. Move an MKV's streams into MP4, or MOV into MP4, without touching the picture.
• Dropping or adding tracks. Remove an audio track, add a subtitle stream, fix metadata.

Beyond stream copy, FFmpeg covers jobs HandBrake was never meant for: joining clips, burning in subtitles with custom styling, extracting audio to MP3, making GIFs with a custom palette, pulling still frames, capturing a screen or webcam, streaming, and any filter graph you can describe. And because it is a command, it fits inside scripts, build pipelines and servers where a desktop app cannot go. If you want the actual commands for the common jobs, the FFmpeg commands cheat sheet decodes every flag.

When is HandBrake's queue the better tool?

When the job is "convert a lot of files the same way, reliably, without thinking about it". This is where HandBrake earns its place.

• Batch encodes. Add a folder of files, apply one preset, start the queue and walk away. FFmpeg can do the same with a shell loop, but you have to write the loop and handle file names with spaces yourself.
• Presets that already made the decisions. HandBrake ships presets grouped for general use, web, devices, Matroska, hardware encoders and production. You pick the one that matches where the video is going, and resolution, frame rate, audio and encoder settings come along with it.
• Discs and old footage. HandBrake scans DVD and Blu-ray sources for titles and chapters. FFmpeg can open individual VOB or M2TS files, but it does not browse a disc structure for you. HandBrake also leans into restoration: deinterlacing and detelecine for combing artifacts, denoise and deblock for tired footage. (It does not defeat copy protection, and its documentation says so.)
• Seeing what you are about to get. A preview window, a visible summary of every setting, and a log you can read afterward. FFmpeg shows you a progress line.

If you prefer to script HandBrake, it has a separate command-line build, so the preset system is not locked to the GUI.

Where does a browser tool fit for a one-off job?

There is a third case both tools handle awkwardly: one file, one job, on a machine where you cannot or would rather not install anything. A school laptop, a work machine with locked-down installs, a borrowed computer, or simply not wanting to learn a new app for one email attachment.

That is the slot VidClip is built for, and I would rather describe it exactly than oversell it. Each tool here runs FFmpeg compiled to WebAssembly in your browser tab. The file is read into browser memory and processed on your own CPU; nothing is uploaded. The recipes are fixed and taken straight from the source code. The compressor, for example, runs x264 with the veryfast preset and yuv420p pixel format, at CRF 23, 28 or 32 for its high, medium and small settings, with AAC audio at 128 kbps and +faststart for web playback. It does not change resolution; that is what the resize tool is for.

The honest limits:

• One file at a time. There is no queue. For a folder of files, HandBrake or a shell loop is the right answer.
• Slower than native. The browser build is single-threaded, so a long 4K encode will take noticeably longer than a desktop encoder using every core.
• Size and watermark on the free tier. Free input is capped at 200 MB and free video exports carry a small corner watermark. Pro removes both, adds lossless stream-copy trim and mute, and adds compression to an exact target size.
• No custom flags. You get the recipe, not a command line. If you need a specific keyframe interval or a two-pass encode, use FFmpeg directly.

Comparison table: which tool for which job

	HandBrake	FFmpeg (command line)	VidClip (FFmpeg in a browser tab)
Install	Desktop app for Windows, Mac and Linux	Binary you install and run from a terminal	None, runs in the browser
Batch queue	Yes, built in	Via your own scripts	No, one file at a time
Lossless cut or remux	No, video is always re-encoded	Yes, with -c copy	Lossless trim and mute on Pro; free exports re-encode
Filters	Deinterlace, detelecine, denoise, deblock, crop, scale and more	The full libavfilter set, any graph you can write	Fixed recipes: crop to ratio, resize, rotate, speed, GIF palette
Presets	Many, grouped by destination	None; encoder defaults unless set	Fixed quality levels per tool
Disc input	DVD and Blu-ray (unprotected)	Individual files only	Individual files only
Learning curve	Moderate: many visible settings	Steep: you must know the flags	Low: pick a file and a setting
Best job	Converting many files to a compatible format with tuned settings	Surgical edits, remuxing, automation, anything unusual	One quick compress, trim or convert without installing anything

Frequently asked questions

Is HandBrake just a GUI for FFmpeg?

No. HandBrake uses parts of FFmpeg's libraries for reading, decoding and some filtering, but it is a separate application with its own pipeline, filters and preset system. It does not run the ffmpeg command. It also exposes only a slice of what FFmpeg can do: no stream copy, no joining clips, no arbitrary filter graphs.

Which gives smaller files, HandBrake or FFmpeg?

Neither, inherently. Both encode H.264 with x264 and H.265 with x265, so the same encoder settings give files in the same range. Size differences come from different defaults: resolution caps, frame rate, automatic cropping, keyframe interval and audio bitrate. Match those and the files converge. If you want smaller, lower the quality target, use a slower encoder preset, or reduce resolution. Compressing video without losing quality covers which lever to pull first.

Can HandBrake cut video without re-encoding?

No. You can set a start and end range in HandBrake, but its own documentation lists passing video through without conversion as something it does not do. For a lossless cut, use FFmpeg with -c copy, a dedicated lossless cutter, or the Pro trim here, and expect the cut to snap to the nearest keyframe.

Is FFmpeg hard to learn?

The basics are not. One input, a few flags, one output covers most everyday jobs, and the rule that trips people up is that options apply to the next file named on the line. The hard part is the long tail: filter graphs, stream mapping and encoder options. Learn the five or six commands you actually need and look up the rest when a job calls for it.

For a single file right now, compress it here with FFmpeg already set up for you, or browse all the tools. Keep HandBrake for the batches.