Every "free online video compressor" works the same way: you upload your file, wait in a queue while their server re-encodes it, then download a watermarked result. For a 200 MB clip on a slow connection, you've uploaded and downloaded 200 MB just to make it smaller — and handed your footage to a stranger's server.
VidCompress takes the opposite approach: for files under 300 MB, the entire compression happens in your browser. The video never leaves your device.
The core idea: WebCodecs
Modern browsers ship a low-level media API called WebCodecs (VideoEncoder / VideoDecoder) that exposes hardware-accelerated encoding directly to JavaScript. That means you can decode frames from a source video, re-encode them at a lower bitrate, and remux the result into a new MP4 — all client-side, no server round-trip.
The flow looks like this:
-
Decode the source with
VideoDecoder(or demux first with an MP4 parser). -
Re-encode frames with
VideoEncoder, configured to a target bitrate derived from your desired output size. - Mux the encoded chunks back into an MP4 container.
Because it uses the OS's hardware encoder where available, it's often faster than uploading the file would have been — and it's completely private.
The hard part: knowing when local will fail
WebCodecs is powerful but uneven. Codec support varies between Chrome, Safari, and Firefox; some inputs (older codecs, unusual color spaces) aren't decodable in-browser; and very large or very long videos can exhaust memory.
So the real engineering work isn't the happy path — it's detecting failure early and degrading gracefully. VidCompress classifies faults into a few buckets:
-
LOCAL_OOM— the file blew the memory budget mid-encode. -
UNSUPPORTED_CODEC— the browser can't decode this input. -
NO_HARDWARE_PATH— the browser can't run the fast local path at all.
When any of these hit, instead of throwing a cryptic error, the app offers a cloud retry: the same job re-runs on a server-side FFmpeg path with a CRF-based quality target. Files over 300 MB skip local mode entirely and go straight to cloud.
This local-first, cloud-fallback split is the whole trick: most everyday clips (phone videos, screen recordings, gameplay) are small enough to stay private and fast, while the rare giant 4K master still has a path that works.
Targeting a size, not a quality
Users don't think in CRF or bitrate — they think "it has to fit Discord." So VidCompress works backwards from a target size:
target_bitrate ≈ (target_size_bytes * 8) / duration_seconds - audio_bitrate
Presets encode the real-world limits that send people looking for a compressor in the first place:
| Destination | Limit | Preset target |
|---|---|---|
| Discord (no Nitro) | 10 MB | < 10 MB |
| 16 MB | < 16 MB | |
| Email (Gmail/Outlook) | 25 MB | < 25 MB |
| Social / Telegram | — | ~50 MB |
What still doesn't work well
Honest limitations, because they matter:
- Long 4K video can still OOM the local path on lower-end devices — that's the most common cloud-fallback trigger.
- Browser variance: Safari's WebCodecs support lags Chrome's, so the local path is more often available on Chromium.
- Audio-heavy edge cases (multiple tracks, exotic codecs) route to cloud.
Try it
If you've ever rage-quit a compressor that uploaded your file and watermarked it, VidCompress is the opposite of that. Files under 300 MB never upload, there's no watermark, and no signup for local mode.
Top comments (0)