Why in-browser video compression beats uploading to the cloud

There is something absurd about the standard way to shrink a video online: your file is too big to upload somewhere, so you… upload it somewhere. A 1.5 GB screen recording crawls up your home connection for ten minutes, waits in a server queue, gets compressed, and comes back down. The compression itself was never the slow part.

SqueezeVid takes the other path: the video never moves. Your browser reads the file from disk, your computer’s own hardware encoder re-encodes it, and the result lands in your downloads folder. This article is about why that is not just more private but usually much faster, and what made it possible only recently.

The upload tax

Home connections are asymmetric: upload bandwidth is typically a fifth to a tenth of download. On a common 20 Mbit/s uplink, a 1.5 GB file takes ten minutes to upload, before any work starts. The cloud compressor then has to do the same decode-encode work your machine could do, and send the result back.

Local processing deletes that entire tax. The only I/O is reading from your own disk, at hundreds of megabytes per second. For large files, the race is over before it starts.

WebCodecs: the browser grew a media engine

For most of the web’s history, browser JavaScript could not touch video frames efficiently; tools that tried shipped ffmpeg compiled to WebAssembly. That works, but it runs the codec in software, single-threaded by default, inside a sandbox with memory limits: often slower than real-time, and prone to falling over on big files.

WebCodecs, shipped in Chromium in 2021 and in Firefox in 2024, changed the deal: it hands web pages the same hardware video encoders and decoders that native apps use, the dedicated silicon in your CPU or GPU that encodes H.264 without breaking a sweat. SqueezeVid is built on it (via the excellent Mediabunny library). On an ordinary laptop, 1080p commonly encodes at several times real-time.

That is the quiet story here: “in your browser” stopped meaning “a toy version of the real thing”. The browser version now uses the same encoder silicon as desktop software.

Privacy as a side effect of architecture

Cloud tools answer “what happens to my video?” with a privacy policy. A local tool answers with architecture: there is no server to retain, scan, or leak your file, because the file never leaves. For screen recordings full of names and dashboards, or family videos, that difference is not cosmetic.

It also makes the economics of “free” honest. Cloud compressors burn real bandwidth and CPU per file, which is why they meter you: three free exports, watermarks, upsells at every corner. When your machine does the work, serving one more user costs the site effectively nothing, and free can just mean free.

What the cloud is still better at

Fairness requires the list: a server can run slower, better codecs (two-pass AV1 at crawl speed) for the absolute best quality-per-byte; a phone with a weak chip may encode slower than a beefy server; and a browser cannot batch a hundred files unattended overnight. If you need those, a desktop tool like HandBrake or a paid cloud service is the right call.

But for the everyday case (this clip must get under that limit, now), the shortest path runs through your own hardware.