How to make a video smaller without guessing
Video compression is a set of measurable tradeoffs, not a mystery slider. Here is what actually changes file size, how to estimate the result, and which setting to adjust first.
The useful file-size equation
For a normally encoded video, file size is approximately combined bitrate multiplied by duration, divided by eight. A sixty-second clip with 1,000 kilobits per second of video and 96 kilobits per second of audio lands near 8.2 megabytes before small container overheads. The encoder may vary around its target, so this is an estimate rather than a byte-perfect promise.
This equation explains why trimming is the cleanest compression available: remove half the duration and you remove roughly half the data without making the remaining frames blurrier. It also explains why changing a filename or container alone does not guarantee a smaller file—the encoded streams inside determine most of the size.
What each control really changes
Bitrate is the encoder's data budget. Lowering it usually has the most direct effect on size, but eventually creates blocking, smearing, or lost detail. Resolution changes how many pixels must be described per frame; a 1920×1080 frame contains four times as many pixels as 960×540, so downscaling can make a limited bitrate look much cleaner. Frame rate changes how many frames arrive each second, although motion and encoder behavior mean the size relationship is not perfectly linear.
The codec decides how those bits are spent. H.264 is a common compatibility choice inside MP4. VP8 and VP9 are common WebM choices. Audio has its own bitrate, and for screen recordings or speech it can be a meaningful share of the final file. Removing audio entirely is better than setting playback volume to zero because the audio stream itself no longer occupies space.
- Trim unwanted time before reducing visual quality
- Downscale when the destination does not need the source resolution
- Lower bitrate gradually and inspect text, faces, and motion
- Keep audio modest for speech; remove it only when it adds no value
- Choose the container and codec for the devices that must play the result
A practical compression order
Start by writing down the real constraint: an attachment limit, a target resolution, or a device that must play the file. Trim first. Next, choose the smallest resolution that still serves the destination. Then estimate a bitrate from the target size and duration, leaving some room for audio and container overhead. Export a short representative section when possible; fast motion, gradients, screen text, and camera noise expose weak settings sooner than a static opening frame.
Do not keep recompressing the previous compressed result. Each lossy generation starts from already simplified frames and can amplify artifacts. Return to the original for every new attempt, change one setting at a time, and keep the first result that meets the delivery constraint while remaining readable.
How local browser compression is verified
HateItAll checks which recording MIME types the browser claims it can encode, disables unsupported MP4 or WebM combinations, and rebuilds the clip locally. Export happens in real time because frames are decoded, scaled, and encoded as the video plays through an off-screen canvas.
After encoding, the tool checks the actual MP4 or WebM container signature and asks the browser to decode the new blob again. Only a result that reopens with readable duration metadata is offered for download. The measured output bytes—not the estimate—are shown beside the source size.
Sources and standards
We used the following format and browser documentation when reviewing this guide: