Reduce Video File Size on Mac Without Losing Quality

Three different things, and conflating them is why people end up disappointed.

The first row is measured, not theoretical. We ran ffmpeg -i bbb.mp4 -c:v libx265 -preset veryfast -x265-params lossless=1 out.mp4 on the source and confirmed the result with -f framemd5: every decoded frame hashed identically to the original. It took 18.3 seconds and produced a file 7.7 times bigger than the H.264 file it started from. That is what lossless costs once a file has already been compressed once.

“Visually lossless” is the useful target. At the top of Smol’s quality ladder, x265 CRF 18 in 10-bit, our clip landed at 15,432,056 bytes and scored VMAF 96.70. That is half the size of the source, and on a laptop display at normal playback speed you are not going to find the difference. Anything above roughly 93 on VMAF is in that territory.

Sometimes, and it is the first thing to check because it is free. The operation is called remuxing: you unwrap the compressed video and audio streams from one container and rewrap them in another, without decoding or re-encoding a single frame.

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

-c copy is the whole trick. On our test clip, MP4 to MKV took 0.31 seconds and produced 30,703,320 bytes against the original 30,704,510. On a 56,384,195-byte screen recording, MOV to MP4 took 0.95 seconds and produced 56,382,367 bytes. We verified both were bit-identical:

ffmpeg -v error -i input.mov  -map 0:v -c copy -f md5 -
ffmpeg -v error -i output.mp4 -map 0:v -c copy -f md5 -
# same hash both times

So be clear about what remuxing does and does not do. It will not make a large file small; container overhead is hundreds of bytes, not megabytes. What it will do is fix the problem that is often mistaken for a size problem: a file that will not play, will not upload, or will not preview. Handing a QuickTime MOV to a web form that only accepts MP4 is a container problem, and re-encoding it to solve that throws away quality for no reason.

There is one stream-copy operation that genuinely shrinks a file, and it is the most under-used tool in this whole subject: cutting.

ffmpeg -ss 0 -t 5 -i input.mp4 -c copy trimmed.mp4

That took 0.58 seconds on our clip and produced 15,715,858 bytes, 48.8% smaller, with no re-encoding whatsoever. The frames that remain are the original frames. If your 90-second screen recording has 25 seconds of you finding the right window at the start, cutting it is strictly better than compressing it. Do that first, then compress what is left.

Two caveats on -c copy cuts. The cut lands on the nearest keyframe, so your start point can drift by a second or two; if you need frame accuracy you have to re-encode. And copying into a container that cannot hold the codec fails outright, which is why -c copy from H.265 into a very old AVI-era container is not a route anyone should plan around.

Once you have decided to re-encode, exactly four things change the size of the output. Here they are on the same 1080p source, each one moved on its own, everything else held at x265 -preset medium:

Reading that table in order of what it buys you:

• Codec is the free lunch. Switching from H.264 to H.265 at matched measured quality saved 30.5% on this clip for no visible cost at all. Nothing else here is free. It is the only lever that gives you bytes back without giving anything up, which is why it should always be the first one you move. The honest caveats are in our tested guide to compressing video on Mac, and they are about compatibility, not quality.
• CRF is the big dial. Five steps of CRF cut the file by more than half and cost 4.3 VMAF points. This is the lever to reach for when you need a specific reduction, and CRF 26 to 28 is where most files should live if they are being sent to someone rather than archived.
• Resolution is brutal but sometimes correct. Halving the long edge cut the file in half again, and cost 12.5 VMAF points because we scored it against the 1080p original. If the video will only ever be watched in a 700-pixel-wide chat window, that penalty is theoretical and the saving is real. If someone might full screen it, do not.
• Frame rate barely helps. Halving 30 fps to 15 fps saved 6.1%. That is the finding most guides get wrong. At a fixed quality target, throwing away every other frame makes each surviving frame more different from the one before it, so each one costs more bits. You lose half the motion smoothness to save a rounding error.

Frame rate does cut file size if you are encoding to a fixed bitrate rather than a fixed quality, because then the bits are rationed per second either way. Almost nobody encodes to a fixed bitrate by hand any more, which is why the advice has aged badly.

Because lossy compression is not idempotent. Every pass decodes the previous pass’s output, including its artifacts, and then compresses that as if it were the truth. The damage accumulates. We ran our clip through the identical x265 CRF 28 command four times, each pass taking the previous output as input:

Each pass shrank the file, which is the trap. A file that keeps getting smaller looks like progress. Quality fell 12.66 VMAF points across four identical commands, and the file only got 39% smaller for it. That is a terrible exchange rate, and here is the measurement that proves it:

Identical perceptual quality, and the single-pass 720p encode is 17% smaller. Everything the four re-encodes achieved, one honest decision about resolution achieved better, in a sixth of the time. When a file has been through the mill a few times, going back to the original and making one good decision beats squeezing the copy again.

Practical consequences: keep the original until the compressed version has been accepted; never compress an export of an export; and if you are tuning settings, always re-encode from the source, not from your last attempt. Smol has a small guard here that is worth knowing about: if a re-compression would not actually improve the file, it keeps the original bytes and reports already optimized rather than quietly handing you a worse copy of the same size.

In order, stopping as soon as the file is small enough.

• Cut the dead time. Stream copy, zero loss, often the largest single saving available. This is especially true of screen recordings, which is covered with measurements in compressing a Mac screen recording.
• Switch to H.265. Roughly 20% to 30% off at the same quality on the content we measured, more on screen captures. No quality cost, only compatibility considerations.
• Raise CRF until it is small enough. Start at 26, try 28, try 30. Check the result before you send it. This is the dial, not the codec and not the resolution.
• Only then drop resolution. And only if you know where it will be watched.
• Leave the frame rate alone unless you are deliberately making a silent loop or a GIF replacement.

One line that covers most of it, verified on the machine described above:

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

-tag:v hvc1 is the part people leave off and then wonder why Finder will not preview the file. If you would rather not think in CRF numbers, Smol maps the same range onto six labels, with web sitting at CRF 28 and the default high at CRF 24, and it will do a folder at a time. It is a one-time $29 purchase, and the upload limits it is usually aimed at are listed in our help article on compressing video for sharing.

If the answer is remuxing. A container change costs nothing and loses nothing, and no compression app should be involved. One ffmpeg line does it in under a second. Same for trimming with -c copy.

If you want mathematically lossless output. We do not offer it, and on an already-compressed source you almost certainly do not want it. If you genuinely need it, -x265-params lossless=1 or FFV1 in a Matroska container are the tools, and you should expect the file to grow.

If you need frame-accurate cuts, filters, or two-pass bitrate targeting. That is HandBrake or ffmpeg. HandBrake is free and actively developed, with its most recent commit dated 25 September 2026, and it is genuinely better than us at transcoding work.

If it is one file, once. QuickTime Player’s Export As is already installed and takes two clicks. It is wasteful with bytes, and for a single clip that does not matter.

Where an app is the right call: a folder of files, a mix of video with images and PDFs, and not wanting to relearn CRF every six months. The document side of the same argument is in how to compress a PDF on Mac.