How to Compress a Video on Mac (4 Methods, Tested)

Four tools, four different jobs. Pick by what you are trying to do, not by which one sounds most serious.

The headline numbers, all from the same 30,704,510-byte 1080p source. VMAF is a perceptual quality score where 100 means identical to the source; anything above about 93 is hard to tell apart in normal viewing.

Read that table twice. QuickTime’s export is more than twice the size of Smol’s default and twelve VMAF points worse. HandBrake’s stock Fast 1080p30 preset lands in the same place. The difference is not the tool, it is the settings the tool hands you.

Measured on 26 September 2026 on a MacBook Pro (Mac14,9) with an Apple M2 Pro, 10 cores and 16 GB of RAM, running macOS 27.0 (build 26A428). Sizes are raw bytes from stat -f%z. Timings are wall clock, single clean run with nothing else encoding. Tools: ffmpeg 8.1.1 from Homebrew, HandBrakeCLI 1.11.2, QuickTime Player as shipped with macOS 27.0, and Smol 1.0.34.

The source is a clip anybody can download and re-run: Big_Buck_Bunny_1080_10s_30MB.mp4. Big Buck Bunny is a Blender Foundation film released under CC-BY 3.0. The file is 1920×1080 H.264 High, yuv420p, 30 fps constant, 300 frames, 10.000 seconds, 30,704,510 bytes, about 24.6 Mbps. A lightly compressed source is the right test subject: it leaves room for a compressor to show what it can do.

That file carries no audio track, and none of the outputs grew one, which we checked with ffprobe on every result. So every byte count on this page is video only. That is deliberate: audio is a fixed overhead that would blur the comparison, and it is the video stream that people are actually trying to shrink.

Quality is scored with VMAF through ffmpeg’s libvmaf filter using the default vmaf_v0.6.1 model, pooled mean across all 300 frames, distorted file against the original. Every output was confirmed to have exactly 300 frames at 1920×1080 first, so the comparison is frame-aligned. Where a file was encoded at a lower resolution it was upscaled back to 1920×1080 with bicubic scaling before scoring, which is the standard way to compare across resolutions.

One methodology note on QuickTime. Its export sheet has no scripting hooks for progress, so each export was started with AppleScript (export document 1 … using settings preset "1080p", which is the same code path as the menu item) and the output file size was polled every 50 ms until it stopped growing. The byte counts reproduced exactly across three separate runs.

Four rungs and a checkbox. Apple documents the whole feature as File → Export As, and the preset list is 4K, 1080p, 720p, 480p and Audio Only. There is no bitrate field, no quality slider, no codec choice. What you get:

Three things worth knowing. Every output is H.264 (avc1), so the Export As list gives you no way to reach H.265 even on a machine whose hardware encodes it natively. The 480p preset means “fit inside 640×480”, so a 16:9 source lands at 640×360, not 854×480. And the exports are fast because they run on the Media Engine, which is also exactly why they are inefficient.

The 1080p export scored VMAF 81.96, PSNR-Y 36.64 dB. Our ffmpeg H.265 encode scored 90.03 in a file 4.3 times smaller. If you export one clip a month for a colleague, none of that matters and QuickTime is the correct answer. If you are uploading video regularly, you are paying for those bytes in storage and bandwidth every time.

Install it with brew install ffmpeg, then one command does the job. This is the line we would give a friend:

ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium \
  -tag:v hvc1 -c:a copy output.mp4

The -tag:v hvc1 part is not optional on a Mac. Without it, Finder, QuickTime and Photos will often refuse to preview the H.265 file even though it is perfectly valid. -c:a copy passes the existing audio through untouched, which is almost always what you want: re-encoding audio you have already compressed costs quality for a handful of kilobytes.

CRF is the only dial that matters. Lower is higher quality and a bigger file. Measured on our clip at -preset medium:

CRF 26 to 28 is the sweet spot for anything headed to Slack, a shared drive or a web page. CRF 23 if it will be watched full screen on a good display. CRF 33 if the real requirement is “under five megabytes” and nobody is going to pause on a frame.

Yes, and anyone telling you otherwise has not checked. The most recent commit on the HandBrake repository as of 26 September 2026 is e40ccade, dated 25 September 2026, and version 1.11.2 shipped on 7 June 2026. It is free, GPL, and better at real transcoding than anything in this article.

Its stock presets on our clip:

The last two rows are the most instructive pair in this whole article. HandBrake’s hardware H.265 preset finished in 3.8 seconds; its software H.265 preset took 32.0 seconds. The hardware file is 33% larger. Hardware video encoders on Apple Silicon are built for realtime capture, not for squeezing bytes, and it shows.

HandBrake’s own documentation is genuinely good, and it publishes the quality ranges most people are looking for when they open the Video tab: RF 18–22 for 480p/576p, 19–23 for 720p, 20–24 for 1080p, 22–28 for 2160p 4K. RF is HandBrake’s name for CRF. If you install one free tool from this page, and you have any interest in the settings, install HandBrake.

Not the encoder. Smol’s video path is software x265, the same library ffmpeg and HandBrake use, which you can confirm from the output file itself:

strings -a output.mp4 | grep -o "x265 (build[^)]*)"
# x265 (build 216)

strings -a output.mp4 | grep -o "rc=crf crf=[0-9.]*"
# rc=crf crf=24.0

That second command is the useful one, because it turns friendly quality labels back into numbers. Smol ships six of them, and here is what each one actually asks the encoder for, measured on our clip. Every output was 1920×1080 10-bit HEVC (Main 10):

Note that the ladder is not a straight line by name: web sits at CRF 28, between balanced at 26 and low at 30. It is a named destination, not a rung. If you would rather set the number yourself, the CRF range is 0 to 63 and all nine x265 encoder presets are exposed.

What the app is actually buying you is the 10-bit default and the queue. Encoding 8-bit source to 10-bit HEVC is a small, unintuitive win: the extra precision reduces banding and improves the rate-distortion curve even when the source has nothing to gain from it. That is why the default at CRF 24 scored VMAF 93.83 in 6,111,954 bytes while x264 at CRF 23 needed 7,462,187 bytes to score 93.30. Same quality bracket, 18% fewer bytes, and nobody had to know what 10-bit means.

One route worth knowing if you live in a terminal: Smol ships an MCP server, so an AI coding agent drives it directly. As of Smol 1.0.35 that means Claude Code, Codex and Google Antigravity, each one click in the app’s AI access panel. In practice you say “compress every MOV in ~/Recordings at web quality and tell me the total savings,” and the agent resolves the paths, runs the job and reports the byte counts, with no shell loop. Details on the MCP page.

This is the single most common misunderstanding in video compression, and it costs people hours of encoding time for nothing. Here is our clip at a fixed CRF 28, changing only the x265 preset:

The slowest preset took 41 times longer and produced a file double the size of the fastest one. If you were watching file sizes and expecting the slow setting to win, that table looks like the encoder is broken.

It is not. CRF is a quality target, not a size target. You tell the encoder how good the picture must be and it spends whatever bits that costs. A slower preset does not spend fewer bits at the same target; it searches harder and therefore actually reaches the target instead of falling short. Look at the VMAF column: ultrafast only got to 80.01, veryslow got to 93.01. They are not producing the same video at different sizes. They are producing different videos.

HandBrake documents this in almost exactly those terms, and its measured table on an Intel Xeon shows the same shape: at RF 24, x265 ultrafast produced 241.8 MB while veryslow produced 317.2 MB. Their wording is that x265’s slower presets “actually increase file sizes while attempting to better preserve quality”.

So where is the payoff for the extra time? It shows up when you compare at equal quality instead of equal CRF. We encoded the clip with the ultrafast preset at CRF 20 to match veryslow’s quality, and then compared:

At the same measured quality the slow preset’s file is 56% smaller. At VMAF 90 the gap is 44%. That is the real trade: encoder presets buy compression efficiency with CPU time, and you only see it by holding quality constant. The practical rule is HandBrake’s: pick the slowest preset that still finishes comfortably fast on your machine, then change CRF when you want a different file size.

H.265 for anything you are storing or sending to a Mac, iPhone or modern browser. H.264 if the file has to work anywhere, unattended, forever.

The headline claim for HEVC is roughly 50% fewer bits at equal quality. On our clip, scored with VMAF, we measured less than that, and we would rather publish our number than repeat the brochure one:

The honest reading: at matched quality H.265 saved us between 18% and 30% on this content, not 50%. The 50% figure comes from standards-body subjective testing at streaming operating points on harder material. Ten seconds of clean animated source, at high quality, scored by an algorithm, is close to the best case for H.264 and therefore the worst case for the comparison. On noisy 4K camera footage the gap widens. On a screen recording it widens a lot, which we measured separately in compressing a Mac screen recording.

The compatibility costs are real and worth naming:

• Tag it or Finder ignores it. H.265 in MP4 needs the hvc1 tag for QuickTime, Finder previews and Photos. ffmpeg defaults to hev1, which is legal and widely unsupported.
• Old Windows and old Android. Windows needed a paid HEVC extension for years, and plenty of machines still do not have it. Anything predating roughly 2017 on Android is a coin flip.
• Editing software and upload pipelines. Some NLEs decode H.265 slowly or not at all, and some upload endpoints transcode it again anyway, which means you paid the quality cost twice.
• Firefox on desktop. Hardware-dependent and patchy. If a video has to play inline on an arbitrary browser, H.264 is still the boring correct answer.

One more result that argues against the obvious shortcut. We also encoded with hevc_videotoolbox, the Apple Silicon hardware encoder: 3,641,139 bytes in 2.0 seconds, VMAF 75.01. Software x265 at CRF 28 produced a smaller file, 3,193,370 bytes, at VMAF 90.03. The Media Engine is roughly three times faster and fifteen VMAF points worse at the same size. Use it when you are encoding in realtime. Do not use it to archive anything.

Decide the target before you touch a setting, because over-compressing a clip you then have to re-export is worse than not compressing it at all.

• Email. Gmail caps personal-account attachments at 25 MB and swaps anything larger for a Drive link. Aim for 20 MB; attachments are base64-encoded in transit and grow about a third on the way.
• Discord and chat apps. 25 MB without Nitro, which an unedited screen recording blows past in under a minute. The concrete numbers for Slack, Discord and email are in our help article on compressing video for sharing.
• A web page. Here the constraint is time to first frame, not a cap. Target the bitrate, not the file size, and serve at the resolution you actually display.
• Archive. Do not compress at all if you can avoid it. If you must, CRF 20 or lower and keep the original until you have checked the result.

None of the CRF-based routes on this page can hit an exact byte count, because that is not what CRF does. If the requirement is literally “under 25.0 MB”, use HandBrake’s average bitrate mode with two passes, or encode at CRF, measure, and adjust. Guessing a bitrate from duration works too: target bytes divided by seconds, times eight, minus the audio bitrate.

The arithmetic changes. QuickTime’s Export As is one file, one save sheet, one preset choice, repeated thirty times. ffmpeg batches happily in a loop, and if you are comfortable writing this, you do not need an app:

for f in *.mov; do
  ffmpeg -i "$f" -c:v libx265 -crf 28 -preset medium \
    -tag:v hvc1 -c:a copy "${f%.*}-small.mp4"
done

HandBrake has a real queue, which is one of the better reasons to use it. What none of them do is take a folder containing video, images and PDFs and handle all three, which is the actual shape of most “make this smaller” problems. That mixed-media case is where a native app earns its money, and it is the same argument we make for documents in compressing a PDF on Mac.

Four cases from this test, and we would rather say so now than after you have paid.

You are doing serious transcoding. Chapters, subtitle burn-in, deinterlacing, cropping, audio track selection, two-pass bitrate targeting, per-title tuning. HandBrake does all of it, for free, and it has been actively developed for two decades. We do not compete with it and we do not pretend to.

You want maximum control and you already know ffmpeg. Then use ffmpeg. Our defaults are a considered opinion about CRF and bit depth. If you have your own opinion, ours is in the way.

You need an exact file size. CRF cannot do it, so neither can we without a measure-and-retry loop. HandBrake’s average bitrate mode is the correct tool.

It is one video, once. QuickTime turned our clip into an emailable file in 2.2 seconds without anyone spending $29. That is a good outcome. If you compress a video twice a year, close this tab and use Export As.

Where we think we earn it: folders rather than files, mixed media rather than only video, a sensible default rather than a settings tab, and nothing leaving the machine. If that is your situation, Smol is a one-time $29 purchase for one Mac. If it is not, everything else on this page is free.