Introducing VidCompress: in-browser video compression for developers who hate uploading files

I got tired of the same routine. You want to shrink a video, you search for a "free online compressor," and it makes you upload the whole file to a server, sit in a queue, and then hands it back with a watermark on it. On a slow connection, a 200 MB clip means uploading 200 MB and pulling it back down again, just to make the thing smaller. And now your footage is sitting on somebody else's machine.

So VidCompress does it backwards. If the file is under 300 MB, the compression runs in your browser and the video never gets uploaded anywhere. Here's roughly how that works, and the parts that still give us trouble.

WebCodecs does the heavy lifting

Browsers have shipped a low-level media API called WebCodecs for a while now — VideoEncoder and VideoDecoder. It hands JavaScript the hardware encoder more or less directly, which is the only reason any of this is possible. You decode the source into raw frames, re-encode them at a lower bitrate, and stuff the result back into an MP4. No server in the loop.

Roughly:

1. Demux and decode the source with VideoDecoder.


2. Re-encode the frames with VideoEncoder at a bitrate worked out from the size you're aiming for.


3. Mux the new chunks into an MP4.

When the OS exposes a hardware encoder — most do these days — this is usually quicker than the upload would have been. And it's private for the obvious reason that nothing leaves your machine.

The annoying part is knowing when it won't work

WebCodecs is great until it isn't. Support is uneven across Chrome, Safari and Firefox. Some files just won't decode — older codecs, odd color spaces. And a long 4K video will happily eat all your memory halfway through the encode.

So most of the real work went into failing gracefully, not the happy path. We sort the failures into a few buckets:

• 
  LOCAL_OOM — ran out of memory mid-encode.


• 
  UNSUPPORTED_CODEC — the browser can't decode this input.


• 
  NO_HARDWARE_PATH — no fast local route on this browser at all.

When one of those fires you don't get a cryptic error. The job quietly retries on a server-side FFmpeg path (CRF-based) instead. Anything over 300 MB skips the browser entirely and goes straight there.

That split — local first, cloud only when it has to be — is basically the product. Phone clips, screen recordings, Discord gameplay captures: small enough to stay on your device and finish in seconds. The occasional giant 4K master still works, it just takes the slower road.

You pick a size, not a "quality"

Nobody opening a compressor is thinking in CRF or bitrate ladders. They're thinking "it has to fit Discord" or "it has to go through email." So we work backwards from the target size instead of asking people to guess a quality slider:

target_bitrate ≈ (target_size_bytes * 8) / duration_seconds - audio_bitrate

The presets are just the limits people actually run into:

If you don't care about a specific app, the plain video compressor just lets you type a number of MB. Either way the job is the same: hit the size, and spend whatever bitrate is left where your eyes will actually notice, so you don't lose quality you'd care about.

Where it still falls down

A few things I'd rather just say out loud:

• Long 4K on a cheaper laptop or a phone will OOM. It's the number-one reason a job ends up on the cloud path.


• Safari trails Chromium on WebCodecs, so the local route shows up more often in Chrome and Edge.


• Multiple audio tracks or unusual audio codecs get punted to the server too.

If you want to twist every knob yourself and you're sat at a desk, HandBrake is honestly still the better tool — I wrote down where we differ from HandBrake if you're weighing it. You're trading an install and a learning curve for "drop a file in a tab, get it back smaller."

So why do the browser thing at all

Mostly privacy. A pre-launch demo, something medical, a private clip — it just never goes anywhere. Speed is the other reason: no upload, no queue, so short clips are done almost instantly. And because there's no server bill on the local path, there's nothing to lock behind a signup or stamp a watermark on.

If you've ever bailed on a compressor because it wanted to upload your file, make you wait, then watermark it — give this one a try. Under 300 MB it stays in your browser. No account, no watermark.