How the size estimate is actually calculated
The bitrate the Video Compressor targets is worked out from the pixel count of the chosen resolution rather than fixed at one number, because a bitrate that suits 1080p would starve a 4K export and waste bytes on a 480p one. Encoding runs through the same hardware video encoder the device already uses to record, and the whole job happens without the file ever leaving the machine.
Resolution is the bigger lever, not quality
Halving both dimensions of a frame removes three quarters of its pixels, a far larger saving than moving the quality setting alone can produce. A recording destined for a phone screen usually looks identical at 720p and is a fraction of the size of the same file left at its original resolution — the quality slider is worth adjusting after the resolution, not instead of it.
It never upscales
Choosing a target resolution larger than the source does not invent missing detail; the output is simply left at whatever resolution the source actually was. The setting is a ceiling, not a promise.
An already-compressed file can come out bigger
A video that was efficiently encoded the first time has little redundancy left to strip out, and re-encoding it spends bits reproducing the artefacts already baked into that first pass rather than removing anything meaningful. Where that is likely, the estimate says so before the run starts, and the result confirms it afterwards — the original is usually the better file to keep in that case.
Which setting is actually worth choosing
For sharing or posting to the web, 1080p at a balanced quality covers almost everything without a visible trade-off. For a phone screen or a messaging app, 720p is usually indistinguishable from the original and considerably smaller again — most video is never watched at a size where the difference would register. The smallest-file setting is worth reaching for only when a hard size limit forces it, since it is the point where the saving starts to cost visible quality.
Where sound needs a different container
Audio is re-encoded as AAC into the MP4 wherever the browser can write AAC. Firefox cannot, on any platform, and no browser can on desktop Linux — a limitation of those browsers, not of this tool. Rather than deliver a silent MP4 on those systems, the export switches to WebM with Opus audio instead, which keeps the sound. WebM plays natively in every current browser and in most media players and editors; the only real cost is a file that says .webm rather than .mp4, which some older software that only expects MP4 will not open. The page says which format was used before you download.
Why MP4 sources finish sooner
An MP4 is read directly: the frames are pulled out of the container and handed to the decoder in sequence, so no individual frame costs anything beyond decoding it. Anything the demuxer cannot read — a WebM source, or an unusual MP4 variant — falls back to stepping the video element to each frame in turn and capturing it, which works with any file the browser can play but pays a seek for every single frame. If a source is slow to process, converting it to MP4 first and then compressing is often quicker than compressing it directly.
Keep the tab in front
Browsers throttle background tabs heavily, and an encode running behind another window slows down or stalls outright. This matters most on the slower fallback path, where each frame is already waiting on the video element, but it is worth doing whichever path a file takes.