A screen recording that turned into a 4 GB file, and why

You record a twenty-minute walkthrough and the file is 4 GB. A colleague records the same length of the same kind of thing and theirs is 90 MB. Neither of you changed any settings.

The difference is almost never a setting. It is what was on screen, and how many pixels the Mac was recording.

Content is the dominant variable, by a very large margin

Video compression works by storing what changed between frames. A frame identical to the one before costs almost nothing; a frame where everything moved costs a great deal.

Measured on 1080p30 clips of identical length and identical encoder settings, varying only what was on screen:

Content	Per minute	Per hour
Mostly static (a document, a slide)	0.2 MB	11 MB
Full-motion detail (video, animation, scrolling)	45 MB	2.7 GB
High-bitrate capture of the same motion	175 MB	10.5 GB

That is a spread of more than two hundred times, from content alone, with nothing else changed. It explains the whole mystery. A recording of slides with a cursor moving occasionally is tiny. A recording that includes a video playing, an animated interface, or a lot of fast scrolling is enormous.

The practical consequence: if your recording is huge, look at what was moving before you look at settings.

Retina scaling doubles the pixel count twice over

The second cause is resolution, and on a Mac it is easy to record far more pixels than you intended.

A Retina display reports itself as, say, 1440 by 900 points while containing 2880 by 1800 actual pixels. Screen recording captures the pixels. So a recording of what looks like a modest window can be well beyond 4K in real terms.

Four times the pixels does not mean four times the file, but it is a substantial multiplier on top of whatever the content costs. Recording a 5K display in full produces very large files even for quite static content.

Two ways to reduce it. Record a selected portion of the screen rather than the whole display, which is offered in the macOS screenshot toolbar (Command-Shift-5). Or reduce the display resolution before recording, in System Settings under Displays, which lowers the captured pixel count directly and often makes the result more readable for the viewer anyway.

Check what you actually recorded

Before compressing anything, look at what the file contains:

ffprobe -v error -show_entries stream=width,height,r_frame_rate,codec_name \
  -show_entries format=duration,size,bit_rate \
  -of default=noprint_wrappers=1 recording.mov

The three numbers that matter are width/height, bit_rate, and codec_name. A 3840 by 2160 recording at a high bitrate in a lightly compressed codec is your explanation.

QuickTime screen recordings in particular are encoded for capture speed rather than for size, so they are deliberately generous with bitrate. They are working files, not delivery files, and converting them afterwards is the expected workflow rather than a workaround.

Shrinking what you already recorded

For a recording that is finished, re-encoding gets most of the size back. HEVC is the efficient choice on a Mac, and hvc1 tagging keeps it playable in QuickTime and Safari:

ffmpeg -i recording.mov -c:v libx265 -crf 28 -tag:v hvc1 \
  -preset medium -c:a aac -b:a 128k smaller.mp4

-crf 28 is a quality target rather than a size target: lower numbers mean better quality and larger files, higher numbers the reverse. For screen content, values between 26 and 30 usually look clean, because text and interface elements compress well once the encoder is not being rushed.

If the recording is 4K and will be watched in a browser window, scaling down saves far more than any codec change:

ffmpeg -i recording.mov -vf scale=1920:-2 -c:v libx265 -crf 28 -tag:v hvc1 \
  -c:a aac -b:a 128k smaller.mp4

-2 keeps the aspect ratio and ensures an even height, which some encoders require.

Frame rate is the third lever. Screen content rarely needs 60 frames per second, and halving it to 30 removes a substantial amount of data:

ffmpeg -i recording.mov -vf "scale=1920:-2,fps=30" -c:v libx265 -crf 28 \
  -tag:v hvc1 -c:a aac -b:a 128k smaller.mp4

Manatee does the same job without the command line, and does it on the Mac rather than by uploading the recording somewhere, which matters when a screen recording contains a customer’s data or an internal system. It works from a duplicate, so the original recording is still there if the compressed version turns out too aggressive. Making a screen recording smaller covers the settings in more depth, and shrinking a video to a specific file size is the approach when there is a hard upload limit to hit.

Recording smaller in the first place

Cheaper than fixing it afterwards:

• Record a region, not the whole display. Most walkthroughs need one window.
• Drop the display resolution before recording if you are capturing a Retina screen in full.
• Avoid playing video inside a screen recording where you can. It is the single most expensive thing you can put on screen.
• Turn off animated wallpaper and anything that moves continuously in the background.
• Pause rather than letting the recording run while you think. Dead time still costs full price if anything on screen is moving.

When the recording will not play at all

Very large recordings are also the ones most likely to be interrupted, by a full disk or a crash, and an interrupted MP4 or MOV loses the index written at the end of the file. The result is a large file that reports no duration and will not open.

That is repairable when the frame data survives: the index can be rebuilt from what is there. QuickTime says the screen recording failed to save covers that case specifically, including where macOS leaves the partial file.

Questions

Why is my colleague’s recording so much smaller? Compare what was on screen first, then the display resolution. Those two account for nearly all of it. Identical settings on different content routinely produce a hundredfold difference.

Does HEVC play everywhere? On current Macs, iPhones and Safari, yes. For maximum compatibility, particularly older Windows machines, H.264 remains the safe choice at the cost of a larger file. H.264 versus HEVC covers who can open what.

Can I compress without losing quality? Not literally, since any re-encode discards some information. At -crf 26 to 28 on screen content the difference is genuinely hard to see, while the file is a fraction of the size. Keep the original until you have checked the result.

Is it better to record in a smaller resolution or shrink afterwards? Record smaller. Scaling down afterwards works, but you spent disk and encoding time capturing pixels you then threw away, and the intermediate file still had to fit somewhere.