Why is my screen recording file so big?

A five‑minute screen recording shouldn’t weigh a gigabyte — and yet there it is in the finder, ticking upward while it records. The weight isn’t mysterious: it’s a handful of multiplied numbers, and knowing which ones you control is the difference between recordings you keep and recordings you delete to free disk space.

Where the weight comes from

A video file is pixels × frames × seconds × compression. Screen recording multiplies hard on the first two: a 4K display is about 8.3 million pixels per frame, and at 60 fps the recorder stores eight of those every tenth of a second. The compression side has an interesting wrinkle — screen content is mostly static (toolbars, code, text that isn’t moving), which modern encoders exploit well when allowed to. The bloat happens when the recorder doesn’t: capturing at full rate without letting the encoder skip unchanged regions.

Add the extras and the number climbs again — a camera PiP track, a microphone track, system audio — each one stored alongside the screen layer. The file isn’t one video; it’s three or four, glued together.

The cost isn’t just disk

The gigabyte hits three times. Once on disk. Again on sharing: attach it to a ticket or a chat and you’re uploading what the cap allows or nothing at all — this is why “the recording is too big to send” quietly kills bug evidence. The third hit is on playback for whoever receives it: a heavy file stutters on machines that shouldn’t struggle with video, and laggy recordings get blamed on the receiver’s hardware when the weight was baked in at capture time.

The four levers, in order of painlessness

1. Capture at the frame rate the content needs. UI work has no motion that 30 fps loses; 60 fps earns its weight only for genuinely fluid motion. Halving the frame rate roughly halves the screen layer.
2. Let the encoder see the screen. Hardware encoders with screen‑aware settings store unchanged regions as “unchanged” instead of re‑describing them. This is where a well‑built recorder quietly beats a generic one.
3. Resolution to destination. A demo shipping to a page that displays 1080p doesn’t gain anything from 4K. Export to the destination’s real resolution; keep the 4K master only if you’ll re‑export.
4. Trim before you keep. The two minutes of “finding the menu” at the top of the take is pure weight. Transcript‑based trimming makes this a deletion, not an editing session — cut the words, cut the footage.

What good looks like

For honest context: a polished demo that’s mostly UI motion at 1080p should sit comfortably under chat‑upload caps for its whole length, and a bug‑report capture should be an order of magnitude below that — short, trimmed, and one region of the screen, not all of it. The GIF export is the extreme case of the same levers: fewer colors, fewer frames, fewer pixels, silent — small enough to live in a README.

I make Snapbak, where these levers are the defaults rather than settings you hunt for: screen‑aware hardware encoding up to 4K60 in the background, tracks you can keep or drop, and an editor that trims before anything gets shared. Weight that disclosure accordingly — and check any recorder’s output the same way: record two minutes, look at the file, do the math.

The whole capture app weighs less than one of those bloated recordings: Snapbak is a 19.8 MB bundle, free for the first 100 users — download it and record your next demo without checking disk space first.