A video compressor is a program that re-encodes a video from one set of encoding choices into a smaller, more efficient set while keeping the picture watchable. Compression works by trading spatial detail per frame, lowering the frame rate, capping the bitrate the encoder is allowed to spend, or combining all three levers, and the resulting file plays back in a standard container that the receiving device already supports. A browser-based compressor like the Video Compressor achieves the same result without uploading the source: the page decodes the chosen video locally, draws each frame into a Canvas, and re-records that Canvas as a WebM stream using the browser's built-in MediaRecorder. Because the recorder observes the Canvas stream while the source plays on the page, encoding runs in real time, so a two-minute clip takes roughly two minutes to finish rather than completing instantly.
What a Video Compressor Actually Does to a File
A digital video file is, at its core, a stream of pictures played back at a fixed cadence plus a synchronized audio track. Every frame carries some amount of detail, and every second of footage carries a budget of bits the codec is allowed to spend describing those frames. A video compressor reduces the file size by squeezing those two budgets: it lowers the spatial detail per frame, lowers the cadence at which frames are stored, lowers the bitrate the encoder is permitted to use, or any combination of the three.
The math is straightforward even when the codec internals are not. A source that records 30 frames per second at 1920 × 1080 already produces more raw pixel data per second than a 24 fps source at 640 pixels wide. When the compressor caps the output width to 640 and the cadence to 24 fps, the stream simply has fewer pixels to describe every second. Constraining the bitrate further forces the codec to spend fewer bits on each second of footage, which usually means more aggressive quantization in regions the encoder considers less perceptually important.
Three things follow from this. First, output quality is always limited by what the original captured, because a heavily compressed, noisy source cannot be magically sharpened by re-encoding it. Second, the trade-off is real, so smaller files mean coarser detail or choppier motion rather than both kept at full fidelity. Third, the result is content dependent, because the same bitrate can describe a clean talking-head clip far more efficiently than grainy concert footage or fast camera shake.
How a Browser Video Compressor Re-Encodes Locally
A standard installable encoder such as FFmpeg reads the source file, decodes each frame, runs the frames through a new codec configuration, and writes a new file. A browser-based tool like the Video Compressor replaces the disk read and write with the browser's media stack. The page takes the chosen video, calls captureStream on the underlying HTMLMediaElement, draws each frame into an opaque Canvas at the preset's resolution and frame rate, and pipes that Canvas into HTMLCanvasElement.captureStream. A MediaRecorder then encodes the resulting MediaStream into a WebM Blob using whatever VP9, VP8, or generic WebM MIME type the current browser reports as supported.
Two practical consequences fall out of that design. First, the source never leaves the tab, because no upload step exists and the network sees nothing about the file's bytes, name, duration, or codec. Second, the recorder can only work as fast as the source plays, since it observes the Canvas stream in real time. Skipping ahead or speeding up playback is not possible without breaking the recorded stream, which is why the page keeps the source playing while the progress bar advances at the natural cadence.
Audio follows the same path when the browser exposes a capturable audio track through HTMLMediaElement.captureStream, which most modern browsers do for a range of codec and container combinations. When the audio track is captured, it is appended to the recorded stream, and when it is not, the output plays back silently. The tool does not normalize, remix, or otherwise process the audio, so device volume controls the listen-in during processing without changing what reaches the recorded stream.
The Three Presets and What Each One Targets
The Video Compressor exposes three named choices rather than a free-form quality slider, and each preset is a fixed bundle of width, frame rate, and bitrate behavior. The defaults are documented in the tool's own contract rather than inferred from category norms, so the table below reflects what each preset actually does in the page.
| Preset | Maximum output width | Target frame rate | Typical use |
|---|---|---|---|
| Small | 640 pixels | 24 fps | Quick sharing where byte count matters more than motion smoothness |
| Balanced | 1280 pixels | 30 fps | General-purpose sharing where detail and motion both need to stay legible |
| Quality | 1920 pixels | 30 fps | Best picture the tool can produce, still bound by the WebM recorder |
Three rules apply to every preset. First, the output never enlarges the source, so a 720-pixel-wide clip stays at 720 even when the preset would have allowed 1280. Second, aspect ratio is preserved, and the chosen width scales the height to match. Third, the output dimensions are rounded down to even pixel values, because many video codecs prefer even widths and heights for block alignment. A bounded bits-per-pixel heuristic chooses the bitrate the recorder requests, and that request is clamped to a range of 180 kbps through 8 Mbps so the recorder never falls outside what the browser can actually produce.
How to Compress a Video Locally in Your Browser
- Open the Video Compressor page in a current desktop browser. The tool is browser-based and runs entirely in the tab.
- Choose a video file the browser can decode. Files may be named MP4, WebM, MOV, M4V, or Ogg, but a valid extension cannot make an unsupported codec decodable, because the installed browser decoders decide what plays.
- Confirm the source stays within the published limits: no larger than 500 MiB, no longer than five minutes, no side longer than 4096 pixels, and no decoded area larger than 3840 × 2160. Anything outside those bounds is rejected before encoding begins.
- Select Small, Balanced, or Quality. Each preset caps width and frame rate as described above, so pick the one whose trade-off matches your goal.
- Start compression and keep the tab open with the source playing. The recorder observes the Canvas in real time, so leaving the tab or closing the source mid-stream can invalidate the active job.
- When the source ends, review the reported output dimensions, the input and output byte counts, and the measured percentage change. Those values come from the actual Blob sizes, and the tool does not label a larger output as a reduction.
- Download the WebM and play the downloaded file fully, including its audio, before deleting the original. Compression is content dependent and the recorder varies by browser, so the only verification that matters is the one you run on the file you actually received.
What the Tool Reports and Why the Output Can Be Larger
When the source finishes playing, the page reports four concrete values: output dimensions, input bytes, output bytes, and a signed percentage change derived only from those two Blob sizes. The formula is the standard signed change over the original.
Worked example. Suppose a 50 MB source encodes to 12.5 MB. The signed change is (12.5 − 50) / 50 × 100, which equals −75%, and that is what the page displays. If instead the same source encodes to 55 MB, the same formula returns (55 − 50) / 50 × 100 = +10%, and the page shows +10% rather than rounding or relabeling the result as a reduction.
Honest reporting matters because compression is not guaranteed. A low-motion animation often shrinks dramatically, while noisy concert footage, grain, rapid camera shake, or an already efficient codec can produce an output that is similar in size or even larger than the source. The recorder also varies between browsers even with the same preset and the same source file, because the tool asks the browser for VP9, then VP8, then generic WebM in that order and uses whatever the browser reports as supported. When a preset does not suit the source, the right next step is to try a different preset rather than to assume the page has misreported.
Limits, Errors, and What the Compressor Does Not Preserve
Several categories of information that the source file may contain are not carried over into the WebM. Subtitles, chapters, attachments, rotation tags, and color or HDR metadata are not preserved by this tool, because the Canvas-MediaRecorder path has no channel for them. The container is WebM because browser MediaRecorder support for generated MP4 is still inconsistent across engines, and the tool prefers the container that will actually produce a file.
Six specific failure conditions cancel the job without producing a download. An invalid file or an unsupported decoder triggers an error. A source longer than five minutes, with a frame larger than 4096 pixels on either side, or with a decoded area above 3840 × 2160 is rejected before encoding begins. A Canvas stream the browser refuses to expose or a WebM MIME type that MediaRecorder will not accept aborts the recording. None of these cases silently truncate the source or hand back a half-finished file, so the output is either a complete Blob or no Blob at all.
Choosing a new file, switching presets, canceling mid-run, or closing the tab invalidates the active job and releases the temporary Object URLs that would otherwise hold the source and output alive in memory. Anything that needs to survive a reload must be downloaded before the tab closes.
When a Desktop Encoder Is the Right Choice Instead
For day-to-day sharing, a browser compressor is usually enough: it stays in the tab, it produces a playable WebM, and it reports what actually happened. For archival masters, professional delivery specifications, exact codec profiles, two-pass rate control, fixed keyframe intervals, subtitle preservation, or deterministic output that has to match across machines, the right tool is a maintained desktop encoder with a reviewed command, with FFmpeg as the canonical example.
The reason is not that browser compression is bad at what it does. The reason is that the Canvas-MediaRecorder path is designed for broad compatibility and quick local use rather than the precise knobs a delivery spec demands. If the destination requires a particular GOP structure, a specific audio codec inside MP4, or HDR signaling that has to survive the trip, a real encoder with a maintained command line is the safer choice. For everything else, including sharing a clip by message, trimming storage, or attaching a smaller version to an email draft, the browser path is the quicker one.
For a closer look at the accuracy side of the same tool, the Video Compressor accuracy walkthrough covers what the reported numbers can and cannot promise in more detail.