A compression tool for screen recordings usually gives you four knobs: a quality preset, a resolution dropdown, a frame rate dropdown, and an output format. I assumed all four were variations on the same trade — give up some picture, get back some megabytes. After turning them one at a time on the same clip, it turned out three of them cost me almost nothing readable, and exactly one of them ate the text. That one is the knob most people reach for first.
Here is what I measured on, because the numbers don't mean anything without it. I wrote a script that draws an admin dashboard and recorded it: 62 seconds, 1920×1080, 30 frames per second, with a skeleton loader, a warehouse filter dropdown, a modal form, and a long table scroll. Every brand name, product name and SKU in it is invented. The important part is how it was captured — the way a screen recorder saves things when it barely compresses, storing each frame whole instead of computing the difference between frames. That is why the file is 295.7 MB. Every percentage below rests on that. If your recorder already compressed the clip once, there is much less left to squeeze.
The tool was ImgIng (https://imging.ai/), picked because there is no signup and the whole thing runs inside the browser — I kept the network panel open through every run and nothing went out in the video direction. My method was to change one dropdown per run and pin the other three to "keep original", which is the only way to tell which knob did what.
Resolution is the only one that touches small text. Resolution is how many pixels wide and tall a frame is; 1920×1080 means 1920 across. I measured legibility by taking the table region, where the SKU codes are 11 pixels tall, and averaging the brightness difference between neighbouring pixels — the crisper the strokes, the higher the number. The source clip scores 4.15. Capping the long edge at 1280 drops it to 2.81. Capping at 854 drops it to 1.36, and at that point the SKU codes are simply not readable any more.
And the 1280 step didn't even buy me anything. Keeping the original resolution produced a 20.32 MB file. Choosing "long edge 1280" produced 25.73 MB — 26.6% bigger than not shrinking at all. The interface tells you why if you read the numbers it prints: the 1280 option is budgeted at 3200 kb/s, while the original-resolution option gets 2502 kb/s. Bitrate is how much data is spent describing one second of picture. Two thirds fewer pixels, more data per second, and the file grows. I paid 14 dB of small-text quality for a larger file.
The other three are much cheaper. Dropping the output format from MP4 to WebM with AV1 — codec meaning the algorithm that turns frames into a file, where MP4 usually carries H.264 — took the same clip from 20.32 MB to 6.4 MB, another 67% off, with sharpness moving only from 4.13 to 4.09. That was the single biggest saving of the four. In the same round VP9 came out 19.7% larger than H.264 on this particular recording, which I am not going to generalise from one clip. AV1 also isn't always offered: the tool probes whether the current machine can encode it and only then unlocks the option.
Frame rate — how many pictures per second, so 30 fps is thirty stills a second — was second. The dropdown only offers 60, 30 and 24. Going from 30 to 24 took 20.32 MB down to 17.39 MB, a 14.4% saving, and the sharpness number did not move at all, still 4.13. I am not calling that free. Twenty-four frames means 372 of the original 1860 pictures are gone, a fifth of them, and what is gone is motion continuity — whether the cursor glides or stutters. My comparison samples frames at fixed wall-clock timestamps and compares them one by one, which is structurally blind to dropped frames. It found nothing because it cannot see there. I have no measurement of smoothness, so I won't claim one.
The quality preset was third. Four steps from top to bottom moved the file from 22.37 MB to 15.84 MB, another 29%, while the small-text region lost 0.42 dB and the sharpness sat at 4.13 the whole way. Zoomed 3× the SKU codes look identical across all four. One oddity worth knowing: the preset labelled "smart" produced 22.37 MB while the one labelled "visually near-lossless" produced 20.32 MB. The names run backwards from the behaviour.
So the order I would use now is the reverse of my instinct: change the codec, then the frame rate, then walk the preset down, and only think about resolution when all of that isn't enough.
One judgement sits above all four, though: look at what you actually recorded. With the default settings untouched, this mostly-static dashboard walkthrough went from 295.7 MB to 21.34 MB — 92.8% off. A clip I built where the entire frame changes every frame only gave up 45.9% on the same settings, and its distance from the source fell from 46.17 dB to 26.52, which is visibly mushy. A slide-style meeting recording gave up 40.7%. Ninety percent is a property of "large static areas, lots of text, local motion", not a property of compression. If most of your screen is holding still, the default preset probably already does the job. If the whole frame is moving, don't plan around that number.
Top comments (0)