Video Compressor re-encodes a browser-decodable video into a WebM file entirely inside the current browser tab, applying one of three bounded output choices—Small caps width at 640 px at 24 fps, Balanced caps width at 1280 px at 30 fps, and Quality caps width at 1920 px at 30 fps—while keeping the source within 500 MiB, five minutes, and a 3840 × 2160 pixel ceiling. The tool draws each displayed frame into a Canvas, records that Canvas stream with the browser's MediaRecorder, and reports the actual input bytes, output bytes, and signed percentage change so you can see whether compression actually shrank the file before downloading it. Because the encoder observes the playing source in real time, processing a two-minute clip takes roughly two minutes rather than completing instantly, and audio plays locally if the browser exposes a capturable audio track. That makes the practical answer to how do I use video compression a short, local workflow: pick a file, choose a preset, let it play through, inspect the reported byte change, and download only after you have played the resulting WebM end to end.
How Video Compressor Works Locally
All four stages—decoding, Canvas drawing, MediaRecorder encoding, and download—run inside the current tab. The browser's decoder reads the source file, each played frame is drawn into an opaque Canvas sized to the preset's maximum width and the source's aspect ratio (rounded down to even pixel values for broader codec compatibility), and the Canvas stream is captured by MediaRecorder using whichever WebM codec the browser reports first—VP9, then VP8, then generic WebM, as documented in the MDN MediaRecorder reference. A capturable audio track is appended only when HTMLMediaElement captureStream exposes one through the source media element.
These stages are governed by hard limits that keep memory, Canvas allocation, and real-time work predictable. The input is validated against each of these checks before the encoder starts: extension or MIME present, positive whole byte size up to 500 MiB, decoded duration above zero and at most 300 seconds, each frame side at most 4096 px, and decoded area at most 3840 × 2160 px. Anything outside those limits produces an error and no download—nothing is silently truncated, and no partial file is offered for save. The Matroska container is finalized with parsed Segment Info and TimestampScale plus an inserted Duration float so the downloaded WebM plays with finite duration in standard players.
Comparing the Three Presets
The three presets are transparent product choices rather than claims about a universal optimum. Each one caps the output width, picks a target frame rate, and lets a bounded bits-per-pixel heuristic choose the requested recorder bitrate, clamped from 180 kbps through 8 Mbps. Aspect ratio is preserved, the source is never enlarged, and output dimensions are rounded down to even values.
| Preset | Max output width | Target frame rate | Typical use |
|---|---|---|---|
| Small | 640 px | 24 fps | Drafts, previews, low-bandwidth sharing |
| Balanced | 1280 px | 30 fps | General-purpose delivery, social uploads |
| Quality | 1920 px | 30 fps | On-screen playback, archival viewing |
If you want help deciding which fits a specific destination, the guide on how to choose the right approach for video compression walks through the same presets with a destination-first lens.
How to Use Video Compressor Step by Step
- Pick a browser-decodable video that does not exceed 500 MiB, five minutes of duration, or 3840 × 2160 pixels of decoded area. The file extension may be MP4, WebM, MOV, M4V, or Ogg, but actual decoding still depends on the codecs installed in the current browser—a valid extension cannot make an unsupported codec decodable.
- Select Small, Balanced, or Quality based on your destination, then start compression. Keep the tab open while the source plays through in real time, because MediaRecorder observes the Canvas stream as it plays rather than processing frames ahead of schedule. The page tracks progress from source playback time and stops stream tracks after recording.
- When the source ends, read the reported input bytes, output bytes, and signed percentage change to confirm the result actually shrank. A noisy, high-motion, or already-efficient source can produce a similar or larger file, and the tool will not relabel it as a reduction—the displayed percentage is calculated only from the two actual Blob sizes.
- Download the WebM, play the complete file with sound in a player that supports the recorded codec, and only then delete the original after picture, audio, duration, and compatibility match your destination. Choosing a new file, changing presets, canceling, or leaving the page invalidates the active job and releases temporary object URLs.
Open the Video Compressor page and run through those steps in order; the rest of this article explains what the report means, why results vary, and when a different tool is the right answer.
Why a Result Can End Up Larger
Compression is content dependent, so the same preset produces very different output sizes on different footage. A simple animation or a static talking-head clip may shrink dramatically because adjacent frames are similar and the bits-per-pixel heuristic can request a low bitrate. The same preset can produce a file of equal or greater size on footage that contains grain, camera shake, fast motion, fine texture, or codecs that already compressed the source efficiently. The percentage shown is always calculated from the two actual Blob sizes—never from a marketing estimate—so the number reflects what really happened on disk rather than a target the tool is trying to hit.
If the result is not what you wanted, try another preset rather than re-running the same one. Small requests a smaller width and a lower frame rate; Quality requests more bits at 1920 px wide. As a rough direction, expect the largest drops on low-motion content and the smallest drops (or growth) on noisy, high-detail footage—the exact figures come from running the tool on your actual file. For a closer look at how those numbers are computed and reported, the Video Compressor accuracy guide explains the byte-change calculation in detail.
What the Output Does Not Preserve
WebM is the only output container because MediaRecorder support for browser-generated MP4 remains inconsistent across browsers, and the page picks the first WebM MIME the browser reports. Several input features therefore do not carry over: subtitles, chapters, and container attachments; rotation tags, color metadata, and HDR signaling; volume normalization, track mixing, or audio repair. This utility does not normalize volume, mix tracks, remove metadata according to a certified standard, repair corrupt media, or preserve every container feature.
Audio is included only when the browser exposes a capturable track through HTMLMediaElement captureStream, so if the source plays audibly during processing you should hear it—but do not assume muting the tab leaves the captured track intact. Use device volume if needed and verify the downloaded file plays with sound end to end. Browser support and codec combinations vary, which is why the same preset and source can produce slightly different output on different browsers, and the recorder tries VP9, then VP8, then generic WebM based on what the current browser supports.
When to Switch to a Desktop Encoder
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. The browser pipeline is excellent for quick, local, no-Upload compression when the destination accepts WebM and you can verify the result before deleting the source, but it does not replace a command-line encoder when you need reproducible, spec-driven output.
If the bottleneck is shape rather than size, several related tools stay in the same local browser workflow without uploading anything: Video Resizer outputs a bounded exact or aspect-preserving WebM, Video Cropper crops a browser-decodable video to an exact in-frame pixel rectangle, and Video Trimmer cuts a bounded section. Each reports what it actually produced so you can decide before deleting the original.