Video size is bitrate multiplied by time, and nothing else
The arithmetic of video is simpler than people expect and it is the whole game. A video file is approximately its bitrate multiplied by its duration. Nine megabits per second for ten minutes is about 675 megabytes, and no amount of choosing "high quality" in a menu changes that relationship. If you need a two minute clip to fit under 16 MB for WhatsApp, you have roughly 1,000 kilobits per second to spend, and every decision after that is about how to spend them.
This is why a quality slider on a video encoder is a worse interface than it is on an image encoder. With a still image you can encode, measure and retry in a fraction of a second. A video encode is minutes of work, so guessing a setting and discovering the result was 40 MB is expensive in a way that guessing at a JPEG is not. The size has to be planned before the encode, not discovered after it.
So this tool works backwards from the target. It takes the duration, subtracts what the audio track needs, and derives the video bitrate that fits the remaining budget, then encodes once at that bitrate. The audio matters more than people expect at small targets: 128 kbps of stereo AAC over ten minutes is about 9.6 MB, which is most of a WhatsApp limit before a single frame of video is encoded. At aggressive targets, dropping the audio to mono at 64 kbps buys back more than any video setting will.
Where the budget per second gets genuinely small, resolution has to come down too. Bitrate is spread across pixels, so 1,000 kbps looks acceptable at 640x360 and looks like a smear of blocks at 1920x1080. The encoder has the same number of bits either way; the question is whether it is describing two million pixels per frame or two hundred thousand. Reducing resolution is not giving up, it is spending the budget where it survives.
The encoding runs in your browser through ffmpeg compiled to WebAssembly. That engine is about 30 MB, which is why it loads only when you actually compress something and never on the landing page. It is also why the video route is the one page on this site served with cross-origin isolation: threaded WebAssembly needs SharedArrayBuffer, and SharedArrayBuffer needs headers that would break ordinary advertising scripts, so that route gets them and no other route does.