Screen Recording Codecs: Why File Size Varies So Much
A recording comes out three times larger than expected, or plays fine on one machine and refuses to open on another, or turns blocky exactly during the parts that mattered, and there's rarely an obvious setting to blame for any of it. Record the same five minutes at the same resolution twice. Once typing in a text editor, once playing a fast-moving game. And the file sizes can differ by an order of magnitude. The codec is doing more work than most people realize.
Container and codec are two different things
A file extension like .mp4 or .webm describes the container. The wrapper format that holds video, audio, and metadata tracks. Not how the video itself is actually compressed. The compression is handled by a separate codec (H.264, H.265/HEVC, VP9, AV1), and the same container can hold video encoded by more than one codec. Two .mp4 files can use completely different codecs internally, which is why file size and even playback compatibility can vary between two files with an identical extension.
That's also usually the real answer to "why won't this file open on my other computer." The container extension looking identical says nothing about whether the codec inside is one the other device can decode; an .mp4 encoded with H.265 can fail to play on hardware that only has H.264 decoding built in, even though .mp4 files "should" just work everywhere.
Codecs compress mostly by exploiting redundancy between frames
Video codecs get most of their size reduction not from compressing individual frames harder, but from noticing that consecutive frames are usually very similar and only storing what changed. A "keyframe" stores a full image periodically; the frames in between store just the difference from the previous frame. A technique called inter-frame prediction. This is exactly why screen content compresses so well: a recording of someone typing in a text editor has huge static regions frame to frame, so the codec has very little new information to store per frame. A recording of a fast-scrolling page or a video game changes almost every pixel every frame, giving the codec far less redundancy to exploit. Hence the size difference at identical resolution and duration.
Newer codecs trade encoding effort for smaller files
H.264, standardized in 2003, remains the most universally compatible codec. Nearly every device with hardware decoding support handles it, which is why it's still the safe default. H.265/HEVC and VP9 typically produce files 30-50% smaller than H.264 at equivalent visual quality, and AV1 (newer still, royalty-free) pushes that further, but all three require more computation to encode and, for HEVC and AV1 especially, don't have universal hardware decode support on older devices. The tradeoff is smaller files against slower or more resource-intensive encoding and playback.
Bitrate is the setting that actually controls the size
Resolution and frame rate set how much raw information exists per second of video; bitrate is the budget the codec is given to represent that information, and it's the single biggest lever on file size independent of codec choice. A capped, constant bitrate gives a predictable file size but can visibly degrade quality during fast motion; a variable bitrate lets the encoder spend more data on complex frames and less on static ones, which is why most modern screen recorders default to variable bitrate. It fits naturally with how uneven screen content actually is from frame to frame.
If a recording looks fine on playback but turns to blocky mush specifically during fast motion, that's usually not the codec failing, it's the bitrate budget running out at that moment. The encoder had a fixed data allowance per second, and fast motion is the most expensive kind of frame to represent accurately within it.
What to actually do about it
If the goal is a smaller file, lower the bitrate or switch to a newer codec like H.265 or AV1 if both your encoding and playback devices support it; recording just the active window instead of a busy desktop also helps, since it gives the codec less change to track frame to frame. If the goal is a file that plays everywhere without a second thought, stick with H.264 in an .mp4 container; it's the slower, larger, more universally compatible choice for a reason. If the goal is avoiding blocky motion, raise the bitrate rather than the resolution: more data per second gives the encoder room to represent fast-changing frames accurately, where extra pixels alone won't help.
Record your screen and see how resolution and content affect the output directly with the screen recorder.