Stop uploading private videos: a browser-only approach to compression
I used to treat “compressing a video” as a simple problem. Pick a file, upload it, wait, download the smaller version.
Then reality hit:
The video was private (family footage, internal work recordings, client material).
The file was huge (hundreds of MB to multiple GB).
The network was slow (or simply too expensive).
The “free” tool slapped a watermark on it or required a signup at the last step.
Compression is a utility. It shouldn’t force you to trade privacy for convenience.
That’s why I built a local-first compressor that runs entirely in your browser using WebAssembly.
Try it: https://compressvideo.net/
Source (demo repo): https://github.com/xzmhxdxh/compressvideo-wasm
The idea: local-first, not “upload-first”
“Local-first” doesn’t mean offline-only. It means:
You can use a web page to get a great UX
But the actual file processing happens on your device
Your video bytes never have to leave your machine
In practice, the workflow looks like this:
Select a video file
The page loads an FFmpeg engine compiled to WebAssembly (FFmpeg.wasm)
FFmpeg runs inside the tab and produces a compressed MP4
You download the result instantly
No server storage. No opaque retention policy. No surprise watermark.
Why this works now
Two things have changed in the last few years:
WebAssembly got good enough to run real workloads in the browser
The ecosystem around FFmpeg.wasm became stable enough to build product-quality flows
For video utilities, that’s a big deal. Uploading is often the slowest and riskiest part of the experience.
A simple default: good quality, smaller size
Most people don’t want to learn bitrate math. They want a smaller file that still looks good.
So the default approach is intentionally boring:
H.264 output (compatible everywhere)
CRF-based quality control (the “set it and forget it” way)
A sensible resolution cap for typical sharing flows (1080p)
AAC audio at a conservative bitrate
It won’t be perfect for every scenario, but it covers a surprising amount of real-world usage.
The trade-offs (the part nobody advertises)
Local compression is powerful, but it’s not magic.
1) Memory limits
Your browser is not a video workstation. It has memory limits, and large videos can push it over the edge.
2) Mobile browsers are especially tight
iOS browsers can terminate heavy pages earlier than desktop browsers. If your workflow is “compress a 2GB video on an iPhone”, a cloud fallback may be the right tool.
3) CPU and battery
Encoding is CPU-heavy. That’s true on servers, and it’s true on laptops. Local-first means you control privacy, but you also spend local compute.
Local-first as a principle
I don’t think every tool should be local-only.
But for private videos, local-first is a default worth fighting for:
You get privacy “for free” (because nothing is uploaded)
You avoid network bottlenecks
You remove a huge chunk of trust surface area
And when the file is too large or the device is too constrained, you can always offer a cloud option as a fallback — transparently and intentionally.
Try it
CompressVideo.net: https://compressvideo.net/
Source code (demo repo): https://github.com/xzmhxdxh/compressvideo-wasm
If you try it and it breaks on a specific device or file format, I’d love to know the details. Those edge cases are where local-first utilities get better.
