Why this compresses in real time
Most in-browser video tools reach for ffmpeg compiled to WebAssembly, which is genuinely excellent and would encode far faster than real time. It is not an option here, and the reason is worth stating plainly: ffmpeg.wasm needs SharedArrayBuffer, which browsers only expose to pages that are cross-origin isolated. Turning on the headers that grant that isolation would break the advertising that keeps this site free. So the choice was between a faster tool that could not exist and a slower one that can.
What runs instead is built from browser APIs that need no special headers. The video is played back, its frames are captured as a live stream, and MediaRecorder encodes that stream at the bitrate your settings imply. When you change the resolution, frames are drawn onto an off-screen canvas at the new size and the canvas is recorded instead. Audio is taken from the same capture and encoded at 96 kbps, or dropped entirely if you tick mute.
The direct consequence is that compression takes as long as the video. A ten-minute clip needs ten minutes. It also means the tab has to stay in front — browsers throttle and stop rendering background tabs, and a paused playback is a stalled recording. Trimming is therefore doubly valuable: cutting a clip in half halves both the output size and the time you wait for it.
What the settings actually control
Resolution is the lever that matters. File size scales with pixel count, and the steps here are larger than they look: 1080p holds 2.07 million pixels per frame, 720p holds 0.92 million — dropping one step removes 56% of the pixels before any compression is applied. Going to 480p leaves under a fifth of the original. For anything watched on a phone screen or in a chat window, 720p is generally indistinguishable from 1080p, and 480p is perfectly watchable.
Quality sets a target bitrate calculated from the output's pixel count, an assumed 30 frames per second, and a bits-per-pixel figure for the level you picked. That target is handed to the browser's encoder as a request, not a guarantee, which is why the live estimate is an estimate — the encoder decides how closely to follow it. Resolution is never upscaled: choosing 720p for a 480p source leaves it at 480p.
| Preset | Resolution | Quality | Aimed at |
|---|
| Discord | 360p | Tiny | The tightest attachment limit of the set — the most aggressive preset here. |
| WhatsApp | 480p | Smaller | Chat video that will be watched on a phone. |
| Gmail | 720p | Smaller | Email attachments where the limit is moderate but real. |
| X / Twitter | 720p | Balanced | Social video that still needs to look decent full-screen. |
| Instagram | Original | Balanced | Keeps the frame size, reduces the bitrate — for platforms that re-encode anyway. |
Honest limitations
The output format is not yours to choose. The tool asks the browser for MP4 with H.264 first and takes what it can get. Chrome and Edge generally provide it; Firefox falls back to WebM, which is a fine format that a surprising amount of software — iMessage, older televisions, some video editors — will not open. If MP4 matters, use a Chromium-based browser.
Re-recording playback is not the same as transcoding a file. A proper encoder reads every frame from the source. This approach captures frames as they are played, so if the machine struggles and the player drops frames, the recording is missing those frames permanently. The frame rate is also assumed to be 30 for the bitrate maths, and a 60fps source captured through the resizing path is recorded at 30 — which halves the motion smoothness of gameplay or slow-motion footage.
Already-compressed video often gets bigger. Footage from a modern phone, or anything downloaded from a streaming service, has usually been encoded more efficiently than the bitrate target here. Re-encoding then adds bytes rather than saving them, and the tool says so instead of pretending otherwise. Check the live estimate before you start — it will warn you — because the alternative is discovering it ten minutes later.
Missing pieces. No two-pass encoding, no codec selection, no frame-rate control, no cropping or rotation. Subtitle tracks, chapters and metadata are not carried through. The encoded output accumulates in memory until it finishes, so a very long recording is limited by available memory as well as by patience.
Getting under a limit
Work in this order, because it is the order of impact. First trim: most videos have dead time at the start and end, and removing it costs nothing in quality while cutting both the file size and the wait. Then drop the resolution one step, which is the single biggest saving available. Only then reduce quality, because that is the setting that produces visible blocking and smearing in motion.
Mute the audio if it contributes nothing — a silent screen recording or a clip destined for captions. It is a small saving in absolute terms but free when the audio is not wanted.
Read the estimate before committing. It updates as you change settings, and it is the difference between choosing sensibly and waiting out a ten-minute encode to find the result is still too large. If the estimate is close to your limit, go one step further rather than cutting it fine — the real output can land either side of the prediction.
Practical notes for the encode itself: keep the tab in front, keep a laptop plugged in, and do not switch the source file mid-run. For a short clip destined for a chat thread, video to GIF may suit better than a compressed video, and video to MP3 extracts just the audio when the picture is not the point. The rest are grouped on the audio & video page.