HandBrake Alternatives for Mac (Without the Settings Maze)

Five jobs where HandBrake is the correct tool and paying us $29 would be a mistake. We would say the same in an email.

The source is a disc, or behaves like one. HandBrake reads DVD and Blu-ray structures, picks titles and angles, and pulls the subtitle tracks along with the video. Smol has none of that. If your input is a folder of VIDEO_TS or a Blu-ray rip with five audio tracks, this is not a close call.

The footage needs repair, not just compression. Interlaced camcorder footage, telecined film, blocky old downloads, video grain that wrecks compression efficiency. HandBrake’s filter set covers detelecine, comb detection, three deinterlacers, deblock, NLMeans and HQDN3D denoise, chroma smoothing, sharpen, colorspace conversion and grayscale. Smol ships zero filters. Running a denoise pass before encoding will beat any amount of clever rate control, and only one of these two apps can do it.

Subtitles, chapters or specific audio tracks matter. A film with forced subtitles on the foreign-language scenes, a lecture recording where you want the chapter markers preserved, a concert file where you need the 5.1 track downmixed to stereo but the original kept. HandBrake does all three. Smol does none of them.

You are not on a Mac. HandBrake runs on Windows and Linux. A macOS-only $29 app is worthless on a Windows workstation, and pretending otherwise would be silly.

You want a scripted, reproducible pipeline you control. HandBrakeCLI takes a preset JSON file and a shell loop, it is free, and it will still work in ten years because the source is public. That is a better foundation for an archive project than any GUI, including ours.

The line is not capability. HandBrake wins on capability almost everywhere. The line is how much of that capability you have to engage with to get one video from 1.2 GB down to something you can email.

Because the encoder preset does not control file size. It controls how much computation the encoder is allowed to spend chasing a quality target you set somewhere else. Those are different dials, and HandBrake puts them on the same tab.

This is the complaint that turns up again and again in forum threads and support requests: someone switches from medium to slow or slower, waits three times as long, and gets a larger file than before. It feels like the app is broken. It is not. HandBrake’s own performance documentation states the behavior outright, and the two sentences sit next to each other:

“Generally speaking, the additional computation performed by x264’s slower encoder presets creates smaller files, and sometimes increases quality very slightly (usually negligibly).”

“However, the significant computation time required by x265’s slower encoder presets make encoding extremely slow even on powerful computers, and actually increases file sizes while attempting to better preserve quality.”

Read that twice. The same word, slower, does opposite things to file size depending on which encoder you chose from a dropdown three rows above it. That is not a documentation failure. It is an accurate description of two encoders that make different trade-offs, exposed through one shared label.

The mechanism is simpler than it looks. In constant quality mode, RF is a target for how much distortion you will tolerate, not a target for bytes. The encoder walks the video and, block by block, decides whether spending more bits is worth the quality it buys. A slower preset gives it more ways to decide well: more motion search, more reference frames, more rate-distortion optimization, more transform sizes to try.

With x264, better decisions usually mean the encoder finds cheaper ways to represent the same picture, so the file shrinks. With x265, the slower presets switch on psycho-visual tools that try harder to keep detail a faster preset would have quietly discarded. Keeping detail costs bits. The picture ends up closer to the source and the file ends up bigger, which is nobody’s expectation of a speed slider.

So the user reporting that the slower speeds take longer and produce larger files is reporting the software working correctly. The bug is in the mental model, and the mental model came from the label.

There is a second, nastier version of this. HandBrake’s quality documentation notes that for x264, x265 and SVT-AV1 a lower RF number means higher quality, and then: “This is reversed for other encoders, such as Apple VideoToolbox, where a higher number produces higher quality.” Pick the hardware encoder on a Mac and the number you learned to trust now means the opposite. HandBrake handles this honestly by making the slider always increase quality rightward, but the number printed beside it still flips.

And a third: an already-compressed H.264 file re-encoded at RF 18 gets bigger, because RF 18 asks for more fidelity than the source contains. The encoder cannot invent detail, so it spends bits faithfully reproducing the old compression artifacts. That is the most common cause of “why is my HandBrake output larger than the original”, and it has nothing to do with presets.

Two things, in this order. Change RF. Then, if you have time to spare, change the preset. Leave everything else alone.

RF is the size dial. It is the only control that reliably moves file size in a predictable direction: lower number, higher quality, bigger file. HandBrake publishes recommended ranges for x264 and x265, and they are good starting points rather than folklore.

Ranges published by the HandBrake project in Adjusting quality, read 26 September 2026. They are not comparable across encoders: RF 22 on x265 and RF 22 on SVT-AV1 are different requests.

Higher resolutions tolerate higher RF numbers, which feels backwards until you think about it. There is more information in a 4K frame, so a given amount of loss is a smaller fraction of the whole and harder to see.

The preset is the time dial. HandBrake’s advice is to “choose the slowest encoder preset that encodes comfortably fast on your computer, and accept subtle quality and file size variations.” That is the right instruction and it contains the honest admission: the variations go both ways. If a slower preset gives you a bigger file at the same RF, you got better quality for those bytes. If you wanted a smaller file, raise RF by two and leave the preset alone.

The tunes, profiles, levels and advanced options string exist for people solving a specific compatibility problem. Without one, changing them makes your file worse and your encode longer.

Because a transcoder’s job is producing a file that works on a named target, and that target might be a 2013 Roku, a PlayStation, a web page or a broadcast deliverable. HandBrake ships presets for all of them.

We counted. The official presets page lists 88 current presets in six categories: 24 General, 8 Web, 25 Devices, 16 Matroska, 11 Hardware and 4 Production. A further 31 sit in the deprecated and legacy tables, including an iPod entry and a Windows Phone 8 entry. None of that is bloat from the project’s point of view. Someone is still encoding for a Roku 480p.

The cost lands on the person who has no device in mind. They opened the app because a 1.2 GB screen recording will not go through email, and the first thing asked of them is a preset category. The macOS window then offers Summary, Dimensions, Filters, Video, Audio, Subtitles and Chapters, and the answer lives on the fourth tab.

There is a hardware cost too. HandBrake’s published system requirements list a minimum of 16 GB of system memory for standard and high definition work, and 32 GB for 4K. Apple Silicon support starts at M1. macOS 14, 15 and 26 are listed as Supported; macOS 13 Ventura is marked Deprecated. HandBrake has been a Universal Binary since version 1.4.0, so it runs native on Apple Silicon.

One more honest note in HandBrake’s favor, because it undercuts a lazy criticism: it does have Apple Silicon hardware encoding. The VideoToolbox documentation describes H.264, H.265 and H.265 10-bit encoders, hardware decoding on macOS 13 and later, and two ready-made presets under a Hardware category. You just have to know to go find them, and to know that picking them reverses the meaning of the quality number.

It decides for you, and it is willing to be wrong for the two percent of cases where the decision matters.

Smol’s shipped video defaults are four values: container mp4, codec h265, quality high, resolution original. Drop a file on the icon and that is what happens. There is no preset browser because there are no presets to browse, and there is no device list because the answer for almost everyone is H.265 in an MP4 at the original resolution.

We are not hiding the controls. Smol exposes CRF 0 to 63 and nine encoder presets, named exactly as the encoder names them: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow. Same two dials, same trade-off, same counterintuitive behavior if you go looking for it. They are defaulted rather than demanded.

The other difference is scope. HandBrake’s documentation is blunt about what it is: “HandBrake is a post-production tool” whose purpose is converting video to MP4, MKV or WebM. It will not touch the 40 photos, the client PDF and the voiceover WAV in the same delivery folder. Smol takes all of them in one drop, and writes MOV as well, which HandBrake does not.

For anything repeatable, neither GUI is the right interface. Smol ships an MCP server, so Claude Code, Codex or Google Antigravity can call compression, conversion and metadata stripping as ordinary steps inside a task: get every asset in this directory under a size budget, then carry on with the build. HandBrake answers the same need with HandBrakeCLI and a shell script, which is free and has the advantage of running anywhere. Pick whichever matches the thing driving the work.

Four honest options, including staying where you are, which is the right answer more often than a page like this usually admits.

QuickTime Player deserves more credit than it gets for this. File, Export As, and you get 4K, 1080p, 720p, 480p or Audio Only, with a Format menu on the top two offering “Smaller File Size” (HEVC) or “Greater Compatibility” (H.264), per Apple’s own documentation. No bitrate control, no quality slider, one file at a time. For a screen recording that needs to be 1080p instead of 4K, that is all you needed and it is already installed.

The other comparisons here are written the same way. Squoosh alternatives covers the same encoder-settings problem on the image side. Topaz Gigapixel alternatives handles the upscaling half of the toolbox, including the free option we think most people should take. Smol vs TinyPNG is the local-versus-cloud argument, and what PDF compression presets actually do applies the same “the label is lying to you” investigation to documents.

If the simple one is what you want, Smol is a one-time $29 purchase for one Mac, with no subscription and no per-file limits. If it is not, install HandBrake. It is free, it is better at transcoding, and it will still be here in a decade.