Screen Recording Too Big? Why, and How to Shrink It
By Mark Fulton · 2026-08-27 · 14 min read
Your screen recording is enormous because the recorder made three decisions for you that all assume it is filming motion. It captured every physical pixel of a high density display, it wrote 60 frames a second at a picture that changed maybe twice a minute, and it held a bitrate high enough for a fast pan that never came. None of those are wrong for a camera. All three are wasteful for a window that is mostly a still image with a cursor moving across it. The good news is that screen content is the easiest video there is to compress, because near identical frames cost the encoder almost nothing. The trap is that it is also the easiest to compress badly, since the sharp edges of text are exactly what a compressor discards first. So the fix is not "compress harder." It is: match the frame rate to the content, downscale by a whole number or not at all, encode to a quality target rather than a fixed bitrate, and then look at the smallest text in the result before you keep it.
Below is where the bytes actually went, why text turns to mush when the settings are wrong, what to change in each of the four recorders people actually use, and how to shrink the file already sitting on your desk.
Why is a two-minute screen recording a gigabyte?
Start with the arithmetic, because it makes the rest obvious. File size is bitrate multiplied by duration. In the units people usually have in front of them:
megabytes ≈ (megabits per second × seconds) ÷ 8
Run that backwards on your own file and you learn something immediately. Divide the size in megabytes by the length in seconds, then multiply by 8. That is the bitrate your recorder actually chose. A 700 MB file from a four minute recording works out at 700 ÷ 240 = 2.92 megabytes per second, times 8, so roughly 23 megabits per second. A recorder that produces about 900 MB in two minutes was running near 60 megabits per second, because 60 × 120 = 7,200 megabits, and 7,200 ÷ 8 = 900 megabytes.
Sixty megabits per second is a bitrate that makes sense for handheld 4K footage of a street market. It makes no sense for a slide deck. For contrast, the same two minutes at 10 megabits per second is 150 MB (10 × 120 ÷ 8), and at 3 megabits per second it is 45 MB. Same recording, same readable text, one twentieth of the file. The full walk through of that formula, including how bitrate and resolution trade against each other, is in video compression by the numbers.
Three things push a screen recorder toward the high end of that range.
It captured the backing store, not the window you saw. On a high density display the operating system draws at roughly twice the logical dimensions in each direction. A laptop panel that presents itself as a 1512 by 982 workspace is physically 3024 by 1964, and a full screen capture records the physical grid. That is four times the pixels of what you thought you were recording, before anything else happens.
It wrote frames you did not need. At 60 frames per second, two minutes is 7,200 individual pictures. On a recording of someone reading a document, several thousand of those are byte for byte the same scene as the one before.
It kept a constant bitrate. Recorders that grew out of live streaming default to constant bitrate, because a stream has to fit a network pipe every single second. Constant bitrate means the encoder spends its full allowance whether or not anything moved. A perfectly still slide gets the same megabits as a fast scroll.
Worth appreciating how much compression is already doing here, so you can see the headroom. Uncompressed 4K at 60 frames per second in the usual 8 bit 4:2:0 layout is 3840 × 2160 = 8,294,400 pixels, at 1.5 bytes per pixel that is 12,441,600 bytes per frame, and 60 of those per second is roughly 746 megabytes per second. Your 60 megabits per second file is already about a hundredfold smaller than that. It just stopped a long way short of where screen content can go.
Why does text go mushy when you compress it?
Two separate mechanisms do the damage, and they hurt different things.
The first is the transform. A codec does not store pixels, it stores a block of pixels as a set of frequency coefficients: a few low frequency ones describing the broad brightness of the block, and a lot of high frequency ones describing the fine detail inside it. Quantisation, the step that actually throws information away, zeroes the high frequency coefficients first because they carry the least perceptual weight in ordinary pictures. A photograph of a face survives that happily. Text does not, because text is almost entirely high frequency. A glyph is a hard black to white transition every couple of pixels. Take away the high frequency coefficients and you take away the edges, which shows up as soft, smeared letters and a faint halo of noise around them.
The second is chroma subsampling, and this is the one that explains coloured text specifically. Almost every recorder writes 4:2:0, where brightness is stored at full resolution but colour is not. Microsoft's reference on 8 bit YUV formats for video rendering defines the notation exactly: "4:4:4 means no downsampling of the chroma channels" while "4:2:0 means 2:1 horizontal downsampling, with 2:1 vertical downsampling." So the colour planes carry a quarter of the samples the brightness plane does. The same page explains why nobody considers this a mistake. "Chroma channels can have a lower sampling rate than the luma channel" without a dramatic perceptual cost, because human vision resolves brightness far more finely than colour.
That holds right up until the picture is syntax highlighted code. Black text on white is a brightness signal, so it comes through 4:2:0 largely intact. A one pixel wide red keyword or a blue hyperlink lives in the chroma planes, and those got quartered. The stroke bleeds into its neighbours and the edges fringe. That is not your compressor being cheap, it is the pixel format, and it was decided at capture time.
There is a 4:4:4 mode. Encoders support it, x265 lists i444 among its input formats in the x265 command line options alongside the i420 default. In practice, playback support for 4:4:4 video is patchy enough that shipping a tutorial in it is a bad trade. The realistic mitigations are duller and they work: record at a larger interface font size, keep the picture at native resolution instead of downscaling, and spend a higher quality setting rather than a lower one. Screen content is cheap enough that you can afford quality.
What frame rate does a screen recording need?
Thirty is plenty for anything driven by a cursor and a keyboard, and there is a real reason to go lower for slides. But the honest answer has a condition attached that most advice skips.
Lowering frame rate only shrinks the file if the encoder is targeting quality, not bitrate. Under a quality target, each frame is encoded to a standard and costs what it costs, so halving the number of frames genuinely removes work and bytes. Under constant bitrate, the encoder has been ordered to fill a fixed pipe, and it will do so with 30 frames just as obediently as with 60. You get identical file size and a choppier recording. If you drop to 30 frames per second and the file comes out the same size, that is your diagnosis: your recorder is on constant bitrate.
The second half of the frame rate story is keyframes, and it is where screen recordings hide most of their waste. A keyframe is a complete picture coded from nothing. Every other frame is a description of the difference from what came before. On static screen content a difference frame is nearly free, because the encoder can mark whole regions as unchanged. So the cost of a static minute of video is basically the cost of its keyframes.
Now look at the interval. FFmpeg's codec documentation maps its g option straight onto the encoder's keyint, described as "Maximum GOP size", and x265's own default for --keyint is 250 frames. Live streaming setups routinely override that down to two seconds or less, because a viewer joining mid stream cannot render anything until the next keyframe arrives. That override is the right call for a stream and completely wrong for a recording nobody joins halfway through. At 60 frames per second and a two second interval, a two minute recording of a motionless slide writes 60 full pictures of that slide. The picture never changed once.
Lengthening the keyframe interval on a screen recording is close to free size reduction. It has one real cost: seeking gets coarser, and a stream copy trim can only cut where a keyframe sits, which is the mechanism explained in how keyframes decide where a lossless cut lands.
Which resolution keeps a 4K screen readable?
Downscale by a whole number, or do not downscale at all.
When you halve a 3840 by 2160 capture to 1920 by 1080, every output pixel is the average of exactly one 2 by 2 block of source pixels. The grid lines up. A one pixel text stroke becomes a consistent half tone across its whole length. Scale that same capture to something like 1600 wide instead, a factor of 2.4, and output pixels straddle source pixels unevenly. One part of a letter stroke samples mostly ink, the next part samples mostly background, and the stroke ends up with uneven weight along its length. That is the ragged, slightly dirty look that people describe as blurry text after resizing.
The practical consequence depends on your monitor:
- 4K, 3840 by 2160. Halves exactly to 1920 by 1080. This is the clean one.
- High density laptop panels. A 3024 by 1964 physical capture halves exactly to 1512 by 982, which is the workspace you were actually looking at. Not a standard video size, but exact, and it will look correct.
- 1440p, 2560 by 1440. Halves exactly to 1280 by 720. It does not divide cleanly to 1080p, since 2560 ÷ 1920 is 1.333. On a 1440p monitor, 720p is the sharp downscale and 1080p is the compromise.
- 1080p. Leave it alone. There is nothing to gain and a lot of legibility to lose.
If you do need to change dimensions, the resizer takes explicit pixel values so you can enter the exact half rather than accept a preset that happens to be close.
How do you shrink the recording you already made?
Here is the diagnostic table. Find your recorder, understand what it did, change one setting for next time, and fix the file you have.
| Recorder | Why its output is large | The one setting to change next time | Fix for the file you already have |
|---|---|---|---|
| QuickTime Player / macOS capture toolbar | Captures the display's full physical pixel grid, so a high density panel records at roughly double its logical dimensions in each direction. There is no bitrate or quality control in the interface at all. | Record a window or a selected region instead of the whole screen. If you need the whole screen, set the display to a lower scaled resolution before you start. | Re-encode at exactly half the pixel dimensions, at 30 frames per second, to a quality target. |
| Windows Xbox Game Bar | Its defaults come from game capture, where 60 frames per second and a generous bitrate are the point. Applied to a document, it spends game money on a still image. | In Settings, Gaming, Captures: video quality to Standard and frame rate to 30 fps. | Re-encode at 30 frames per second. Resolution is usually already fine, since Game Bar captures the window. |
| OBS Studio | Recording settings inherit from streaming. Constant bitrate spends the full allowance every second regardless of whether anything moved, and the short keyframe interval a stream needs writes full pictures over and over. | Switch recording rate control from constant bitrate to a quality target (CQP or CRF), and lengthen the keyframe interval. | Re-encode to a quality target. The savings on static content are the largest of any recorder here. |
| Loom and browser tab recorders | They encode live in the page with a bitrate chosen up front for reliable capture, and it does not adapt to a screen that stopped moving. Capturing the whole display rather than one tab multiplies the pixel count too. | Share a single tab rather than the entire screen, and set the capture size to what you will actually publish. | Download the MP4 and re-encode. Live encoded files usually have the most slack of all. |
For the file already on your disk, the order of operations matters and it is short.
Trim first. Cutting dead air at the start and end removes bytes without re-encoding anything, so it costs no quality at all. Do it before you compress, so you are not spending encoder effort on footage you will delete. The trimmer handles that.
Then encode to a quality target, not a size. Constant rate factor asks for a quality level and lets the bitrate float, so still sections get cheap and busy sections get what they need. Target bitrate does the opposite: it holds the rate and lets quality float, which on screen content means overspending on the still parts and starving the one moment you scrolled. The difference, and which quality numbers sit where, is worked through in what "without losing quality" actually means.
Then check the text, not the whole frame. Play the result, pause on the busiest screen in it, and zoom into the smallest text you care about. That is the only quality check that matters for a screen recording, and it takes ten seconds.
You can do all of that in this tab. Drop the file into the compressor and it is read into browser memory and encoded on your own processor. There is no upload bar and no queue, because the file never leaves the machine, which is the whole design of editing video without uploading it. Two things to know before you start: the free tier reads files up to 200 MB, and free video exports carry a small watermark in the corner. Pro lifts both, and adds exact target size compression along with instant lossless trimming. A 900 MB screen recording is past the free input cap, which is a good argument for fixing the recorder settings so the next one starts small.
One codec note. H.265 encodes the same picture in meaningfully fewer bits than H.264, which is attractive here, but it plays back in fewer places and encodes more slowly. The trade is laid out in H.264 versus H.265. For a recording you are about to send to a colleague, H.264 remains the safer answer, and screen content has so much redundancy that you rarely need the newer codec to hit a sane size. The rest of the browser tools are listed at the catalogue.
Frequently asked questions
Why are Mac screen recordings so large?
Two reasons stacked on top of each other. The capture takes the display's physical pixel grid rather than the logical workspace, which on a high density panel is roughly four times the pixel count you assume you are recording. And the built in recorder exposes no bitrate, quality, or frame rate control, so you cannot ask it for a smaller file. The recording is what it is, and the only lever you get at capture time is recording less of the screen: pick a window or a region rather than the full display, or drop the display to a lower scaled resolution before you hit record. Everything else has to happen after the fact.
Does lowering frame rate help screen recordings?
It depends entirely on how your recorder is doing rate control, and this is the part usually left out. If it is encoding to a quality target, then yes, halving 60 frames per second to 30 removes half the frames and a substantial share of the bytes, and cursor movement and typing still look completely smooth at 30. If it is encoding at a constant bitrate, lowering the frame rate changes nothing about the file size, because the encoder is under orders to fill the same pipe per second either way. All you get is a choppier recording at the same size. If you lower frame rate and the size does not budge, you have just diagnosed a constant bitrate setting, and that is the thing worth changing.
Should I record at 4K and downscale?
Usually not, for screen content. Oversampling then downscaling is genuinely useful for camera footage, because averaging pixels together cancels sensor noise and yields a cleaner picture than recording at the target size directly. Screen content has no sensor noise to average away. It is already a synthetic, perfectly clean image. So you pay four times the pixels during capture, four times the encoding work, and then throw away the extra resolution, ending up roughly where you would have been recording at 1080p in the first place. Record at the size you intend to publish. The one exception is if your display is 4K and you cannot change what the recorder captures, in which case downscale by exactly two and you will get a clean result.
Why is my text blurry after compressing?
Check three things in order. First, the scale factor: if you resized to anything other than an exact fraction of the original dimensions, the output pixel grid does not line up with the source and every text stroke gets sampled unevenly. Redo it at exactly half. Second, the quality setting: text is nearly all high frequency detail, which is precisely the information a codec discards first, so a setting that looks fine on camera footage can visibly soften letters. Move one step up the quality scale and compare. Third, if it is specifically coloured text that has gone muddy while black on white looks fine, that is chroma subsampling rather than the compression level, and no amount of extra bitrate will fully fix it. Increase the interface font size for the next recording, and keep the picture at native resolution.