Compress a Mac Screen Recording

Three reasons, and the first one accounts for most of it. To measure rather than guess, we captured a recording on the machine described below using macOS’s own capture tool from the command line, so it is reproducible:

screencapture -v -V 60 -D 1 screenrec60.mov

What came out, straight from ffprobe:

Resolution is the main culprit. macOS records the display at its native pixel size, and on a 14-inch MacBook Pro that is 3024×1964. That is 5.94 megapixels per frame, 2.86 times a 1080p frame. You are recording at better than 4K height without ever choosing to.

The content is hostile to the codec in one specific way. Screen content is mostly static, which is great for compression, but the parts that do change are sharp text and hard-edged UI. Video codecs are built around the assumption that high-frequency detail can be blurred without anyone minding. Text is exactly the case where that assumption is wrong, so the encoder has to spend real bits whenever anything moves.

It is captured in realtime by a hardware encoder. A recorder cannot think about a frame for 40 milliseconds, so it uses the Apple Silicon Media Engine, which is built for speed rather than efficiency. That is the same trade we measured directly in our tested guide to compressing video on Mac: the hardware H.265 encoder was three times faster than software x265 and fifteen VMAF points worse at the same file size.

A useful rule of thumb from two separate captures on this machine: a 20-second recording came out at 20,067,955 bytes and the 60-second one at 56,384,195. Budget about a megabyte per second of Retina screen recording. A ten-minute product walkthrough is over half a gigabyte before you have edited anything.

Everything in this table starts from the same 56,384,195-byte recording, re-encoded with x265 at CRF 28, -preset medium, all 994 original frames preserved with -fps_mode passthrough. Only the one named setting changes per row.

The ranking is the point. Resolution beats everything, the keyframe interval is worth more than most people would guess, frame rate is nearly worthless, and two of the rows made the file dramatically worse. The bottom row is the combination we would actually ship: 98.2% off the source, in under nine seconds.

Here is that command, and yes, it was run:

ffmpeg -i screenrec.mov -fps_mode passthrough \
  -vf scale=1512:982 -c:v libx265 -crf 28 -preset medium \
  -x265-params keyint=600:min-keyint=600 \
  -tag:v hvc1 -c:a copy small.mp4

-tag:v hvc1 is required if you want Finder, QuickTime and Photos to preview the result. Without it you get a valid H.265 file that macOS pretends not to understand.

A keyframe is a complete picture, compressed on its own with no reference to any other frame. Everything between keyframes is stored as differences. On a 5.94-megapixel screen capture, one keyframe is expensive and one difference frame is almost free, because for long stretches of a screen recording nothing at all has changed.

So the interval between keyframes sets how often you pay full price. Our three measurements on the identical recording:

Between the tightest and loosest setting the file changes by a factor of 2.85, with the picture quality target untouched. If a tool is producing a suspiciously large screen recording, a short keyframe interval is a good first suspect. Several capture tools use two seconds, because that is the streaming convention, and streaming conventions exist to let a player seek and switch bitrates, not to make small files.

What you give up by going long is seek granularity. A player has to decode from the last keyframe, so with a 36-second interval, scrubbing can hesitate. For a demo clip that someone watches start to finish, that is a non-issue. For reference footage you will be scrubbing through in an editor, keep the default.

Almost always, yes. A Retina capture stores two device pixels for every point of interface you designed, and the person watching your clip in a Slack thread is looking at it in a box perhaps 700 pixels wide. You are shipping 3024 pixels of width so that a browser can throw most of them away.

Halving the long edge is the single biggest saving available:

The exact-half number matters more than it looks. Scaling by precisely 0.5 maps a clean 2×2 block of source pixels onto one output pixel, which keeps text edges crisp. Scaling to an awkward ratio like 1920 from 3024 resamples on fractional boundaries and softens exactly the thing you most want to stay readable. If you are going to downscale a Retina capture, halve it.

Two things to check before you do. If the recording shows anything at small type sizes, a terminal at 11 point, dense spreadsheet cells, a code editor at its default size, open the downscaled version and read the smallest text in it. That takes ten seconds and it is the only test that matters. And if the clip is a bug report where the exact pixels are the evidence, do not downscale at all; raise CRF instead.

If you would rather not think in pixel dimensions, Smol’s video resolution options are bounding boxes rather than exact sizes. Setting 1920 on this recording produced 1662×1080, because the box is 1920×1080 and a 3024×1964 frame is taller than it is wide relative to that box. Useful to know before you wonder why the output is not 1920 across.

Hardly at all, and this is the advice we would most like to retire. Forcing our recording to a constant 10 fps threw away 39% of the frames and saved 13.8% of the bytes. Forcing 15 fps saved 9.3%.

There are two reasons for that, and both are worth understanding. At a fixed quality target the encoder spends whatever each frame costs; dropping frames means the frames that survive are more different from their predecessors, so each one costs more. And a macOS screen recording is already variable frame rate. Ours declared a 240 timebase but contained 994 frames in 60 seconds, because the capture only emits a frame when something changes. It has already done the frame-rate optimisation for you, and forcing a constant rate on top can make things worse: our 15 fps version contains 902 frames, barely fewer than the original 994.

Where frame rate is genuinely the right lever: a talking-head demo capture where you are deliberately targeting a small, smooth-enough deliverable and you are also encoding to a fixed bitrate rather than a quality target. In that case the bits are rationed per second and fewer frames means more bits each. That is a different mode, and the trade-offs are in reducing video file size without losing quality.

One thing that does work and costs nothing: cut the dead time at the start and end with a stream copy, before compressing anything. No re-encoding, no quality loss, and on a recording that begins with fifteen seconds of you finding the right window it is the largest saving on this page.

ffmpeg -ss 15 -to 75 -i screenrec.mov -c copy trimmed.mov

Drop the file into an app and pick a quality. Smol’s results on the same 56,384,195-byte recording, timed by the app itself:

Note the bottom row is both the smallest and the fastest, by a wide margin, because downscaling first means the encoder has a third as many pixels to think about. That is the same reason the half-resolution ffmpeg run took 9.3 seconds against the native run’s 32.5.

Under the hood there is no magic: the output carries an x265 options string you can read yourself, and the quality labels are CRF values. High is CRF 24 and web is CRF 28, both in 10-bit HEVC.

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

What an app buys you here is the folder case. Screen recordings arrive in batches: one per bug, one per support ticket, one per onboarding step. For the upload limits these are usually fighting, Slack and Discord and email, the current numbers are in our help article on compressing video for sharing. Smol is a one-time $29 purchase for one Mac, and it handles video alongside images and documents, which is the same argument we make for compressing PDFs on Mac.

When the real fix is recording differently. If you are producing screen recordings weekly, capture a smaller region with the Screenshot toolbar’s Record Selected Portion, or record from a scaled resolution. Apple documents the capture options in the Mac User Guide. A 1280-wide capture never needs compressing in the first place, and no amount of post-processing recovers the sharpness you lose by downscaling later.

When you want the trim more than the compression. Cutting with -c copy is instant and lossless. QuickTime Player’s own Edit → Trim does the same job with a slider.

When you need burned-in captions, cursor highlighting or zoom. That is a screen-recording editor, not a compressor. We do not do any of it.

When ffmpeg is already open. The one command in this article is shorter than a paragraph and does exactly what we do. If you are comfortable with it, use it. HandBrake also handles this well, is free, and is actively developed, with its most recent commit dated 25 September 2026.

• Where we do think we earn it: a queue of recordings rather than one, a sane default instead of a settings tab, nothing leaving the machine, and Finder integration so the whole thing is a right-click.