How to compress a video without uploading it

For most of the web's history, "compress a video online" meant uploading it to a stranger's server, waiting in a queue behind other people's files, and downloading the result. The video left your machine, and what happened to the copy afterwards was a matter of trust.

That is no longer necessary. Browsers can encode video directly, using the same hardware encoder your phone uses to record it.

What changed: WebCodecs

Hardware video encoders have been in every phone, laptop and desktop for over a decade — a dedicated block of silicon that does nothing but encode and decode video, which is why your phone can record 4K without getting hot or flattening the battery.

Browsers could not reach it. JavaScript had no API for encoding video, so the only options were uploading to a server or running a software encoder compiled to WebAssembly, which works but is roughly an order of magnitude slower because it cannot touch the dedicated hardware.

WebCodecs changed that. It is a browser API that exposes the platform's own encoders and decoders to JavaScript directly, at full hardware speed. A compressor built on it does the whole job locally: read the file, decode frames, scale them, encode at a chosen bitrate, write a new MP4 — all inside the tab, with no network involved at all.

Support, as of October 2026:

Browser	Video encoding
Chrome / Edge	Yes
Safari 16.4+	Yes
Firefox (recent)	Yes
Older browsers	No — a server-side tool is the only option

Images and PDFs do not need WebCodecs at all. createImageBitmap and OffscreenCanvas have been available for years, so local image and PDF compression works even in browsers without video support.

Why this is faster, not just more private

The privacy argument is the obvious one. The speed argument is the one that surprises people.

Uploading a 200MB video on a typical home connection — 20 Mbps up, which is better than much of the world gets — takes about 80 seconds before any work begins. Then the file sits in a queue, gets encoded on shared server hardware, and comes back down. The download is quick because the output is small, but the upload is dead time you cannot avoid.

Encoding the same file locally starts immediately. There is no upload, no queue, and no round trip — and your machine's encoder is not being shared with anyone. For anything above about 50MB, local is usually faster end to end, and the gap widens the larger the file gets.

There is a second-order effect too: because it costs nothing per file to run, there is no reason to ration it. No daily cap, no watermark on the free tier, no account. Those restrictions exist on server-based tools because every file costs the operator CPU time and bandwidth. Remove the server and the reason for the restrictions goes with it.

What "nothing is uploaded" should mean

The claim is easy to make and worth checking. Three things make it verifiable rather than a promise:

No server-side code at all. If a tool has no API endpoints, there is nowhere for a file to be sent. That is a structural property, not a policy — a privacy policy can change, an absent server cannot start receiving files.

Check it yourself. Open your browser's developer tools, go to the Network tab, and compress a file. You should see the page and its scripts load, and then nothing. No request carrying your file, because there is no request. This is worth doing once with any tool making this claim.

It works offline. Load the page, turn off your network, and compress something. If it still works, the file is not going anywhere. This is the clearest test there is.

Where this genuinely matters

Beyond general preference, there are contexts where uploading is not a neutral choice:

• Legal and medical. Privileged or protected material should not transit a third party's infrastructure, and in many jurisdictions doing so has specific compliance consequences.
• HR and internal investigations. Recordings of people discussing other people.
• Unreleased work. Anything under embargo, or any footage whose leak would matter commercially.
• Documents containing identity data. Scanned passports, bank statements and tax returns are routinely compressed to fit portal limits, and they are exactly the files you least want on an unknown server.
• Poor connectivity. If your upload is slow or metered, a 200MB upload is not a minor inconvenience.

The honest limitations

Local compression is not strictly better in every respect:

• It uses your battery. A long encode on a laptop will warm it up and drain it. Nothing is being sent anywhere, but the work is being done by you.
• Your hardware sets the speed. A five-year-old budget laptop encodes slower than a server. Most of the time the upload you skipped more than covers the difference, but not always.
• Very old browsers cannot do video. Without WebCodecs there is no local video path, and an honest tool says so rather than failing silently.
• The tab has to stay open. There is no job queue to come back to.

Trying it

The compressor on this site runs entirely in your browser — there is no /api directory in the codebase and no server-side component to send anything to. It handles video, images and PDFs, targets an exact byte limit, and measures the output to confirm it came in under before handing it over.

The work happens in a dedicated Web Worker rather than on the page's main thread, which is why the tab stays responsive during a two-minute encode instead of freezing.

Start at 20MB for Discord or 100MB for a larger target, and open the Network tab while it runs if you want to confirm the claim.

FAQ

Can a browser really compress video without a server?

Yes, through the WebCodecs API, which gives JavaScript direct access to the hardware video encoder already in your device. It is the same encoder your phone uses to record video, so the work runs at full hardware speed rather than being simulated in software. Chrome, Edge, Safari 16.4+ and recent Firefox all support it.

Is browser-based compression slower than an online tool?

Usually faster overall, because there is no upload. A 200MB file takes well over a minute to upload on a typical connection before any processing starts, and then waits in a queue. Local encoding begins immediately. On very old hardware a server may encode faster, but it rarely makes up the upload time.

How can I verify my file is not being uploaded?

Open the Network tab in your browser's developer tools and compress a file — you should see no request carrying it. The stronger test is to load the page, disconnect from the network, and compress something anyway. If it works offline, nothing is being transmitted.

Does this work on a phone?

Yes. Mobile Chrome and Safari both support WebCodecs, and phones have good hardware encoders — compressing a clip on the device that recorded it works well. Long encodes will use battery, and the browser may throttle the work if you switch away from the tab.