The output of a browser-based video compressor is WebM because the underlying MediaRecorder API has substantially more consistent support for WebM than for browser-generated MP4. When you select a source and pick a preset like Small, Balanced, or Quality, the page draws each displayed frame into a bounded HTMLCanvasElement, calls captureStream() on that canvas, and hands the resulting MediaStream to a MediaRecorder. That recorder requests a MIME type from the browser — VP9 first, VP8 next, then generic WebM — and the browser returns whichever combination it actually supports. MediaRecorder support for MP4 recording exists in some browsers but remains inconsistent across versions and platforms, so a tool that runs entirely in the page cannot promise a working MP4 output. Choosing WebM keeps the pipeline predictable: the same input, the same preset, the same page can produce a downloadable, playable file in every modern browser, even though the exact codec inside the container can differ between engines.
How the browser pipeline settles on WebM
Every browser-based re-encode you run without uploading the file relies on the same three building blocks: a decoded video element, a canvas that draws what you see, and a recorder that writes the canvas stream to a downloadable Blob. The first piece is straightforward — you point an HTML video element at a local file the browser can decode and play. The second piece is HTMLCanvasElement.captureStream(), which converts whatever the canvas is currently painting into a live MediaStream. The third piece is the MediaRecorder API, which encodes that stream and exposes the result as a Blob you can save.
Where MP4 drops out of the picture is at the third piece. MediaRecorder asks the browser for a MIME type, and the browser answers with the first codec and container combination it actually supports. VP9 inside WebM is widely implemented. VP8 inside WebM is even more widely implemented. Generic video/webm with whatever audio codec the browser offers is the universal fallback. Generated MP4 recording, by contrast, only landed in some engines recently, and even there it depends on hardware encoders that are not always available. A web page has no portable way to know which combination will work, so the safe choice — the one that produces a downloadable, playable file in the current tab — is WebM.
The practical consequence is that the same page, the same source, and the same preset can produce a file with slightly different internals in Chrome, Firefox, and Safari, because each engine picks the first MIME it supports. The container name stays WebM, but the video codec inside might be VP9 on one machine and VP8 on another. That is also why the percentage change reported by the tool is calculated from the two actual Blob sizes rather than from a theoretical target.
What each preset produces inside the WebM container
The three presets on the Video Compressor are transparent product choices about resolution, frame rate, and bitrate, not claims about a universal optimum. They differ only in the upper bounds they impose before encoding begins, and the encoder works within those bounds based on the content of the source.
| Preset | Maximum width | Target frame rate | Bitrate behavior | Typical use |
|---|---|---|---|---|
| Small | 640 px | 24 fps | Lower bits-per-pixel target, clamped between 180 kbps and 8 Mbps | Short clips where absolute size matters more than detail |
| Balanced | 1280 px | 30 fps | Mid bits-per-pixel target, clamped between 180 kbps and 8 Mbps | Sharing, previews, and most web uploads |
| Quality | 1920 px | 30 fps | Higher bits-per-pixel target, clamped between 180 kbps and 8 Mbps | Playback where detail retention matters more than file size |
All three preserve the source aspect ratio, never enlarge the source, and round output dimensions down to even pixel values for broader codec compatibility. If your source is 1280 × 720, Balanced will keep it at 1280 × 720, Small will keep it at 640 × 360, and Quality will keep it at 1280 × 720 because 1920 is wider than the source and the tool does not upscale. The exact bitrate inside the WebM is then chosen by a bounded bits-per-pixel heuristic that respects the cap of each preset and the global 180 kbps to 8 Mbps clamp.
Compress a video locally and download the WebM
The pipeline takes a moment of setup and then runs in real time, so plan your tab accordingly.
- Choose a browser-decodable video no larger than 500 MiB, five minutes long, or 3840 × 2160 pixels of decoded area. The page validates the file, the duration, and the decoded dimensions before it begins; an invalid file, unsupported codec, or over-limit duration produces an error and no download.
- Select Small, Balanced, or Quality from the preset control. The preset sets the resolution ceiling, the target frame rate, and the bits-per-pixel target the bitrate heuristic will use.
- Start compression and keep the tab open while the source plays in real time. Encoding runs at playback speed because MediaRecorder observes the canvas stream as it draws each frame, so a two-minute source takes approximately two minutes rather than finishing instantly.
- When the source ends, review the output dimensions, input bytes, output bytes, and the signed percentage change reported on the page. The percentage is calculated only from the two actual Blob sizes and never labels a larger file as a reduction.
- Download the generated WebM, play it fully in your usual player, and confirm picture, sound, dimensions, and duration before you delete the original. Choosing a new file, changing the preset, canceling, or leaving the page invalidates the active job and releases the temporary Object URLs.
Every step runs in the current tab without uploading the source, and nothing about the file, the thumbnail, the duration, the codec, or the result leaves the device.
When the WebM output fits your destination
WebM with VP9 or VP8 plays in every modern desktop browser, every recent Android browser, and most modern smart TVs and set-top boxes. If your destination is a website you control, an HTML5 video element, a Discord attachment, a Slack upload, a Google Drive preview, or a modern learning management system, the WebM you get from the compressor will usually play as-is. The container is open, royalty-free, and purpose-built for the kind of in-browser playback the tool itself depends on.
Where WebM is awkward is on destinations that still expect MP4 with H.264 and AAC: some older hardware media players, certain professional editing suites with strict import lists, a handful of social-media uploaders, and some corporate intranets that lock down to legacy formats. The WebM you download is also not a final delivery master — it does not preserve subtitles, chapters, attachments, rotation tags, color metadata, or HDR signaling, and the page does not normalize volume or mix tracks. For archival masters, professional delivery specifications, exact codec profiles, two-pass rate control, fixed keyframe intervals, subtitle preservation, or deterministic cross-platform output, use a maintained desktop encoder such as FFmpeg with a reviewed command after downloading the WebM.
Why the compressed WebM can be larger than the source
The percentage shown after a run is honest about bytes, not about a target. Compression depends on motion, noise, source codec, browser encoder, and preset, so a low-motion animation may shrink dramatically while noisy footage, heavy grain, constant camera shake, rapidly changing detail, or an already efficient H.265 source can produce a similar or larger file. The encoder is also constrained by the global 180 kbps to 8 Mbps clamp and the preset ceiling, which means an already-tight source has no room to compress further without sacrificing visible quality. When the result does not suit your needs, try another preset, trim the clip with the Video Trimmer before compressing to remove static segments, or move the source through FFmpeg with explicit rate control after downloading.
What to verify in the downloaded WebM before deleting the source
Always play the downloaded file fully, with sound, on the device or service that matters most. Check that the output dimensions match what the page reported, that the duration matches the source, that audio is present when the source had audio, and that the byte change reflects what you actually wanted. Audio is included only when the browser exposes a capturable track through the source element, so a silent output is not necessarily a bug — it can mean the current browser does not expose an audio MediaStreamTrack for that file. If the WebM is larger than the source, that is also not necessarily a bug; it is the honest measurement of what the encoder produced with the chosen preset and the current browser's available codecs. Decode, Canvas drawing, MediaRecorder encoding, and download all happen in the current browser tab, and the only copy of the original still on your device is the one you have not deleted yet, so verify the output thoroughly before removing anything.
If you're weighing options, What to Review After You Use Video Compression covers this in detail.
If you're weighing options, When Should I Use Video Crop Instead of Doing It Manually covers this in detail.