An upload rejects your file at 25 MB and the recording is 200 MB. The temptation is to run a "compress" button until something fits. That works, but it usually gives up far more quality than it had to, because the three dials that make a video smaller do not degrade it equally.
The arithmetic
File size is, near enough, bit rate multiplied by duration:
size (MB) ≈ (video kbps + audio kbps) × duration (s) ÷ 8 ÷ 1000
Run that backwards to hit a limit. For 25 MB and a 4-minute (240 s) clip:
total kbps = 25 × 8 × 1000 ÷ 240 ≈ 833 kbps
Leave 96 kbps for audio and the video gets roughly 730 kbps. Now the question is a concrete one, does this footage look acceptable at 730 kbps, instead of a vague one about how much to compress.
At that budget, 1080p will look soft and blocky on movement. 720p will look reasonable. 480p will look clean but small. That is the trade being made, and making it on purpose beats discovering it after the upload. The underlying principle is the one image compression runs on: quality is what you spend bits on, and fewer pixels means fewer bits to spend. If the target is an email rather than an upload form, attachment limits are stricter than the number they advertise.
Which dial, in which order
Bit rate, first. Most footage recorded on a phone or a screen recorder is encoded far above what it needs. Screen recordings in particular are mostly static pixels and compress enormously well. Dropping the bit rate by half often costs nothing you can see.
Resolution, second. Halving each dimension quarters the pixel count, so 1080p → 720p is a large saving, and it is the correct move once the bit rate is low enough that 1080p has started to break up. A clean 720p beats a smeared 1080p every time.
Frame rate, last. Going 60 → 30 saves real space, but motion judder is more noticeable than softness, especially in game capture, sport or fast scrolling. For a static talking head or a slide presentation, 30 → 24 or even 15 is invisible and saves a lot.
Why the same settings give different results
Two clips at identical settings can come out at wildly different sizes, because codecs encode change, not frames.
A screen recording of a code editor is mostly identical pixels from frame to frame, so the encoder stores a keyframe and then tiny descriptions of what moved. A handheld shot of leaves in wind has every pixel changing constantly and nothing to reuse.
This is why "compress to 10 MB" behaves so inconsistently across files, and why grain, confetti, rain and shaky handheld footage are the hardest things to compress. If your footage is in that category, expect to give up resolution earlier than you would for a screen capture.
CRF versus target bit rate
Encoders offer two ways to ask for quality.
Constant quality (CRF). You specify a quality level and the encoder spends whatever bits that needs. Complex scenes get more, simple scenes get fewer, and the result looks consistent throughout. You do not know the final size until it finishes.
Target bit rate. You specify the size budget and the encoder fits it, spending the same rate on hard and easy scenes alike. You get a predictable file size and uneven quality.
For archiving or sharing where the size is not fixed, constant quality is the better setting. For an upload limit, target bit rate is the one that answers the actual question. A video compressor that lets you state a target size is doing the second, which is what a hard limit calls for.
Audio is worth checking
Audio is frequently left at 320 kbps on a clip where nobody will notice 96 kbps. On a four-minute video that difference is about 6 MB, which, in the example above, was a quarter of the entire budget.
For speech, 64–96 kbps AAC mono is clean. For music, 128–192 kbps stereo. If the video has no meaningful audio at all, removing the track removes its entire contribution.
A working order
- Trim to the content that matters.
- Decide the hard limit and compute the total bit rate budget.
- Set audio to what the content needs, subtract it.
- Pick the highest resolution that looks acceptable at the remaining video budget.
- Reduce frame rate only if the content is static and you are still over.
- Encode once, from the original.
The video compressor covers steps 4 and 6: it scales the resolution down (never up) and sets the quality, working on the file in the browser tab, so a recording of an internal call gets down to an attachable size without leaving the machine. It does not trim, so if the clip needs cutting, do step 1 first in whatever recorded it.