Compress Videos Without Uploading: Browser-Based Video Compression

Video files are the largest things most people produce. A two-minute screen recording from a phone can be 200 MB. A minute of 4K gameplay footage can be a gigabyte. The usual solutions are all disagreeable: cloud compressors that want you to upload the raw file, desktop apps that cost money and add watermarks, and “free” online tools that cap your file size at 100 MB and queue you behind strangers.

None of that is necessary. The browser can decode, compress, and re-mux a video entirely on your device, with no upload and no file-size limit. The technology that makes it possible is WebCodecs — a browser API that exposes the same hardware-accelerated video encoders your operating system uses for playback. This guide covers how the pipeline works, which codec to pick, and why the result can be half the size of the original with no visible quality loss.

Why no ffmpeg.wasm

The obvious approach to browser-based video compression is ffmpeg.wasm — the full FFmpeg binary compiled to WebAssembly. It works, and it is what most browser-based video tools use. It also downloads a 25 MB WASM blob on every visit, runs entirely on the CPU, and is slow enough that compressing a five-minute clip can take longer than the clip itself.

The alternative is to skip FFmpeg entirely. The pipeline used here splits the job into three pieces, each using the best tool for that specific step:

• Demuxing (splitting the container into encoded video and audio packets) is done by web-demuxer — a small WebAssembly build of FFmpeg’s libavformat, only the demuxer, not the full binary. It runs in a Web Worker and is fetched from a CDN once, then cached.
• Decoding and encoding (the actual compression) is done by the browser’s native WebCodecs API.VideoDecoder unpacks frames from the source, andVideoEncoder re-encodes them at the new bitrate, resolution, and frame rate — using your GPU’s hardware-accelerated H.264, VP9, or AV1 encoder.AudioDecoder and AudioEncoder handle the sound track the same way.
• Muxing (writing the finished packets back into a container) is done by mp4-muxer or webm-muxer — tiny JavaScript libraries that write the container format directly, with no WASM at all.

The result is a pipeline that uses hardware acceleration where it matters (encoding), a minimal WASM blob where WASM is unavoidable (demuxing), and pure JavaScript where it is sufficient (muxing). Your video never leaves the device; the only network requests are the one-time static downloads of the demuxer engine and muxer libraries.

Three codecs, one decision

The codec you choose is the single biggest factor in the output file size. Three output combinations are offered, depending on what your browser can encode:

The size figures are at equivalent visual quality. AV1 is the clear winner on file size, but it is also the slowest to encode — the codec is computationally complex, and even hardware AV1 encoders are slower than their H.264 counterparts. If you need the smallest possible file and can wait, AV1. If you need it fast and universally playable, H.264. VP9 is the middle ground: smaller than H.264, faster than AV1, and native to the web.

The tool detects which codecs your browser can encode and only offers the ones that are available. Safari (from version 16.4) supports WebCodecs but with a smaller codec set than Chrome and Edge. Whatever the input format, the output is always re-encoded to one of these three for compatibility.

Two compression modes: quality and target size

Quality mode maps a 1–100 slider to a bits-per-pixel-per-frame budget, scaled by each codec’s known efficiency. This is the mode to use when you care about visual quality and want the file to be as small as that quality allows. The slider does not map linearly to bitrate — AV1 at quality 50 needs roughly half the bits of H.264 at quality 50, because the slider accounts for the codec’s efficiency. That means quality 50 “looks the same” across codecs, but produces different file sizes.

Target-size mode works backwards from a megabyte goal. You say “I need this under 25 MB for an email attachment”, and the tool calculates the video bitrate from the target size, the clip’s duration, and the reserved space for audio and container overhead. If the target is below the quality floor for that duration — meaning the bitrate would be so low the video would be unrecognizable — the tool tells you, rather than silently producing garbage.

The structural levers: resolution and frame rate

Codec and bitrate are the fine-grained controls. The coarse-grained ones are resolution and frame rate, and they are where most of the size savings come from for typical recordings.

• Resolution caps are applied to the long edge of the video. This is important for portrait phone footage: a 2160p cap on a vertical video means 2160×3840 is capped to 2160 on the long edge (the height), not the width. The tool always caps the correct edge, so portrait video is handled the same way as landscape.
• Frame-rate caps (30 or 24 fps) are the other big lever. A 60 fps screen recording or gameplay clip halved to 30 fps cuts the bitrate nearly in half, with no visible difference for content that is not fast-motion sports or action games.
• Audio drop removes the audio track entirely. For screen recordings with no dialogue, or when you only need the video, this saves the bandwidth the audio track would have consumed.

The tool shows a live estimated output size that updates with every setting change, before you start the compression. It also warns when the source is already so efficiently compressed that the chosen settings may not shrink it — re-encoding an already-small AV1 file to AV1 at the same quality will not help, and the tool says so rather than wasting your time.

Audio: AAC or Opus, handled correctly

Audio is re-encoded to AAC at 96 kbps stereo (64 kbps mono) in MP4, or Opus in WebM. The tool handles channel downmixing and linear resampling when the source audio does not match the target — a 5.1 surround track is downmixed to stereo, a 48 kHz track is resampled if needed.

One subtle detail: phone recordings sometimes carry display rotation metadata (a flag that says “this was recorded in portrait”). The tool preserves that rotation flag in MP4 output, so a vertical video stays vertical after compression — no need to manually rotate. Dimensions are always rounded to even numbers, because video codecs require even-width and even-height dimensions.

Fast-start: why playback begins instantly

The muxer writes the container with fast-start enabled — the moov atom (the part of an MP4 that tells the player how the file is structured) is written at the beginning of the file, not the end. Without fast-start, a player has to download the entire file before it can start playing, because the structural metadata is at the end. With fast-start, playback begins as soon as the first frames arrive.

This is why some compressed videos start instantly while others buffer for seconds before playing — not a bitrate difference, but a container structure difference. The tool always produces fast-start output, so the result is suitable for web embedding and streaming.

What the tool cannot do

• HEVC / H.265 decoding depends on your operating system. H.265 is patent-encumbered, and browsers can only decode it if the OS has licensed the codec. Recent macOS and iOS Safari can decode HEVC; some Chrome builds on Windows can as well; Linux typically cannot. Whatever the input, output is always H.264, VP9, or AV1.
• AV1 encoding is slow. Even with hardware acceleration, AV1 is computationally expensive. A five-minute clip at AV1 may take several minutes on the same machine that would finish H.264 in under a minute. The tool shows live encode speed as a multiple of real-time, so you can see the trade-off happening.
• Re-encoding is lossy. Every compression pass discards information. If you compress a video, then compress the result again at different settings, quality degrades further. Keep the original if you may need another export later.
• Very long files scale with device memory. A two-hour 4K video will use significant RAM during encoding. There is no artificial file-size cap, but very large files on low-RAM devices may fail. Splitting long recordings is the practical workaround.

Privacy, and the honest comparison

Cloud video compressors receive your raw footage. For a screen recording of a presentation, that is mildly uncomfortable. For raw footage of an unreleased product, a confidential meeting recording, a deposition, or a personal video, it is a data-handling event you may be legally responsible for.

Running locally, the video is read from your disk by code inside the browser tab, decoded and re-encoded on your hardware, and saved back to disk. There is no upload progress bar because there is no upload. The only network requests are the one-time static downloads of the demuxer engine and muxer libraries, which are the same for every user and contain none of your data.

Try it with the video compressor — start with a screen recording or phone clip you already have, try it at H.264 quality 50 first, then re-run the same clip at AV1 quality 50 and compare the file sizes. The difference is usually striking enough to make the codec choice obvious for your specific content.