← Blog8 min read
MediaRecorder API: How Browsers Can Compress Video Without Uploading
If you've ever wondered how a website can compress a 200MB video and hand you a 10MB MP4 without uploading anything, the answer in 2026 is usually the same: the MediaRecorder API. It's the browser primitive that lets you re-encode media using the user's own GPU, with no server round trip.
This post is for developers and technical readers. I'll cover what MediaRecorder actually does, the codec and bitrate situation, where it falls short, the WebCodecs alternative, and why VidCompress chose MediaRecorder as the primary compression path. If you're not a dev, skip to the compress page and you can ignore the rest.
What MediaRecorder is, briefly
The MediaRecorder interface is a browser API that takes a MediaStream (from a camera, screen, canvas, or video element) and produces an encoded media blob. It's been stable in Chrome since 2016 and Firefox since 2017, with Safari catching up properly in iOS 17.
The typical signature looks like:
const stream = videoElement.captureStream();
const recorder = new MediaRecorder(stream, {
mimeType: 'video/mp4; codecs="avc1.42E01E, mp4a.40.2"',
videoBitsPerSecond: 1_500_000,
});
const chunks = [];
recorder.ondataavailable = (e) => chunks.push(e.data);
recorder.onstop = () => {
const blob = new Blob(chunks, { type: 'video/mp4' });
// user downloads blob
};
recorder.start();
videoElement.play();
videoElement.onended = () => recorder.stop();
That's the entire client-side compression pipeline conceptually. The browser pulls frames out of the video element in real time, re-encodes them at the bitrate you specified, and hands you a fresh blob. No upload, no server.
Why this matters for video compression
The dominant model for "online video compressor" tools has been: upload to server, FFmpeg on the server, download back. That model has four real costs:
- Bandwidth. A 200MB upload on a 50Mbps connection is 30+ seconds before any processing starts.
- Privacy. Your file lives on the operator's infrastructure during processing.
- Operator cost. Compute, storage, egress — all paid by the service.
- Concurrency limits. Server queues during peak hours.
MediaRecorder flips all four. The bandwidth cost is zero. The privacy story is "the file never left your device." The operator cost is essentially the static site bill. Concurrency is limited only by the user's own CPU/GPU.
The trade-off: encoding speed is bounded by the user's hardware, and you have less control over the encoder than you'd get with a server-side FFmpeg. For a "good enough" compressor targeting common destinations (Email, Discord, WhatsApp), the trade is correct. For frame-accurate professional encoding, it isn't.
Browser support in 2026
| Browser | MediaRecorder | MP4 output | WebM output | Notes |
|---|---|---|---|---|
| Chrome 100+ | Full | Yes (avc1) | Yes (vp8/vp9) | Best support |
| Edge 100+ | Full | Yes | Yes | Same as Chrome (Chromium) |
| Firefox 90+ | Full | Limited | Yes | MP4 output via fallback only |
| Safari 17+ | Full | Yes (avc1) | Limited | MP4 default |
| Safari iOS 17+ | Full | Yes | Limited | Real usability now |
| Safari iOS 16 | Partial | WebM only | Yes | Works but quirky |
| Older browsers | Varies | No | Varies | Fall back to server |
[SOURCE NEEDED: verify exact Safari/iOS MP4 output support at publish time, this changed mid-2024]
Chromium-based browsers are the most consistent. Firefox's MP4 output story is the weakest because of licensing-era reluctance to ship H.264 by default; in practice it works but output may default to WebM unless you specifically request avc1.
Codec and bitrate control
MediaRecorder exposes three knobs that matter for compression:
- mimeType: picks the container and codec. Common choices:
video/mp4; codecs="avc1.42E01E"for H.264 baseline,video/webm; codecs="vp9"for VP9,video/webm; codecs="vp8"for VP8 (most compatible WebM). - videoBitsPerSecond: target video bitrate. The encoder treats this as a target, not a hard ceiling. Variable-bitrate behavior is implementation-defined.
- audioBitsPerSecond: target audio bitrate. Usually fine at 128k for stereo, 64k for mono speech.
What you don't get: keyframe interval control, GOP structure, profile/level tuning beyond what mimeType encodes, two-pass encoding, or rate-control mode selection. The browser picks reasonable defaults and you accept them.
For most "compress this video to fit destination X" workflows, that's enough. Pick bitrate by target size:
// rough heuristic
const targetSizeBytes = 9.8 * 1024 * 1024; // Discord 10MB
const durationSeconds = videoEl.duration;
const audioBudget = 128_000 / 8 * durationSeconds; // ~16KB/sec
const videoBudget = targetSizeBytes - audioBudget;
const videoBitrate = (videoBudget * 8) / durationSeconds;
Subtract a safety margin (5-10%) for container overhead and you'll land within a few percent of the target file size.
Where MediaRecorder falls down
Honest list of pain points if you're building a serious tool on top of this:
- Real-time encoding. MediaRecorder encodes as the source video plays. A 5-minute video takes 5 minutes of wall-clock to compress. There's no "encode as fast as your CPU can go" mode.
- Limited codec choices. No HEVC, no AV1, no fine-grained tuning. What the browser ships is what you get.
- Implementation drift. Chrome's output and Safari's output for the same input and settings can differ measurably in quality and size.
- No frame-accurate cutting. If you want to trim before compressing, you do it via currentTime seeks on the source video, which is sloppy on some codecs.
- Audio sync edge cases. Very long videos sometimes drift a few ms over many minutes.
For 95% of "make this video smaller" jobs, none of this matters. For a professional encoding pipeline, it does, and you'd reach for WebCodecs or server-side FFmpeg.
WebCodecs: the more powerful alternative
WebCodecs is the newer API (Chrome 94+, Safari 16.4+, Firefox 130+) that exposes individual encoder/decoder objects, frame-by-frame. With WebCodecs you can:
- Decode and encode at non-real-time speeds (use CPU as fast as available)
- Pick specific codecs, profiles, levels
- Process frames before re-encoding (filters, overlays)
- Implement two-pass encoding
The trade-offs:
- Significantly more code. WebCodecs is a primitive; you assemble the pipeline yourself.
- Container muxing is your problem. WebCodecs gives you encoded chunks; you have to mux them into MP4/WebM with something like mp4-muxer or webm-muxer.
- Browser support is narrower, especially on iOS until recently.
For VidCompress's current scope (compress to destination presets, browser-local, simple UI), MediaRecorder is the right pick. If we ever need editing features, frame-accurate trimming, or 2x+ speed encoding, WebCodecs is the upgrade path.
Why VidCompress uses MediaRecorder
Three reasons we chose MediaRecorder over a server-side FFmpeg architecture or WebCodecs:
First, the privacy story is genuine. "0 bytes uploaded" isn't a marketing line, it's an architectural property of MediaRecorder. The file never leaves the device because there's no place for it to go. This matters for sensitive content (medical, legal, private) where users won't trust a server-side tool even if it claims to delete files immediately.
Second, operating cost stays near zero. No upload bandwidth, no compute, no storage. We host a static site, serve some JavaScript, and the user's browser does the work. This is how VidCompress can offer unlimited per-day compression on a free tier without burning runway.
Third, MediaRecorder is good enough. For the destinations VidCompress targets — Email (24MB), Discord (9.8MB), WhatsApp (16MB), Telegram (50MB), Social (50MB) — the quality at those bitrates is bounded by physics, not by the encoder. A more sophisticated encoder would not noticeably improve a 9.8MB clip of 60 seconds of 1080p video.
The honest limitation is file size. The largest video MediaRecorder can comfortably handle in a browser tab depends on available RAM (chunks accumulate in memory), and we cap guest uploads at 200MB and free accounts at 300MB. Above that, we'd need to swap chunks to IndexedDB or move to a server-side path. Pro plans address this by offering a planned 5GB cloud upload path for larger files, which does involve a server.
Comparison: where each compression architecture wins
| Architecture | Privacy | Speed | File size ceiling | Encoder quality | Operator cost |
|---|---|---|---|---|---|
| MediaRecorder (browser) | Best | Real-time | RAM-bound | Good | Near zero |
| WebCodecs (browser) | Best | Faster than real-time | RAM-bound | Better | Near zero |
| Server-side FFmpeg | User trusts operator | Very fast | Storage-bound | Best | High |
| Client app (Electron) | Best (with install) | Faster than real-time | Disk-bound | Best | App distribution cost |
For "I just need this smaller for Discord," browser MediaRecorder wins. For "I'm encoding a 4K feature film for theatrical release," server-side FFmpeg or a desktop app wins. VidCompress sits in the first bucket on purpose. The video compressor online overview explains the user-facing version of this trade-off.
FAQ
Why doesn't VidCompress just use FFmpeg.wasm instead? FFmpeg.wasm works but is significantly slower than native MediaRecorder because it doesn't use the GPU. Quality is similar; speed is the issue. MediaRecorder hits hardware-accelerated encoders where available. For a UX-first product, that matters.
Can I trim a video before compressing using MediaRecorder?
Yes, via setting videoElement.currentTime to the start position, calling recorder.start(), then recorder.stop() at the end position. Frame accuracy depends on the source codec; H.264 with frequent keyframes is more accurate than VP9 with sparse keyframes.
What's the smallest practical file size for a 1-minute 1080p clip? Around 3-4MB before quality becomes objectionable for most content. Below that, blocking artifacts and motion blur dominate. The compress MP4 page has more specific guidance.
Does MediaRecorder work in service workers or web workers? No. MediaRecorder requires a live MediaStream, which requires a media element, which requires the main thread DOM. WebCodecs can run in workers, which is one of its advantages.
Is the output deterministic? Roughly. Same browser version + same input + same settings will produce nearly identical output. Different browser engines produce visibly different output at the same settings.
Wrap-up
The MediaRecorder API is the reason browser-based video compression went from "tech demo" to "primary workflow" between 2018 and 2026. For tools focused on resizing and converting to common destinations, it's the right architecture: privacy-preserving by construction, near-zero operator cost, good-enough quality.
VidCompress is built on it. If you want to try the user-facing result, vidcompress.com/compress handles it in your browser, with 0 bytes uploaded anywhere. If you're building your own tool, MediaRecorder is the API to start with, and WebCodecs is the upgrade path when you outgrow it.