Comparing video compression approaches means running the same source through each method under identical conditions and comparing the actual output bytes, dimensions, and playback rather than trusting advertised compression ratios. The most reliable local comparison uses a browser tool that re-encodes a single file with three named presets so the input stays constant while width, frame rate, and bitrate target change one variable at a time. The Video Compressor does exactly this: it plays a browser-decodable source, draws each displayed frame into a bounded Canvas, and records that Canvas as a WebM file while you watch the source play in real time. Because decoding, drawing, and recording all happen in the current tab, you can rerun the same source against Small, Balanced, and Quality presets without uploading anything, then read the reported output dimensions and the signed byte change to decide which preset actually suits your content. This makes preset comparison a reproducible measurement instead of a guess based on a marketing description.
What an "Approach" Means in a Local Browser Compressor
An approach to video compression is the combination of output width, frame rate, and target bitrate applied to a single input. Three named approaches let you isolate the effect of each axis. Lowering width alone tests the cost of resolution; holding width fixed and lowering frame rate tests the cost of temporal detail; lowering the bits-per-pixel heuristic tests the cost of bitrate. Holding the source, container, and encoder constant across runs means any difference in bytes or visible quality comes from the chosen approach rather than from a different codec, a different file, or a different machine. That structure is what lets the comparison say something meaningful about your footage instead of about the tool itself.
What Each Preset Actually Changes
The three presets are transparent product choices rather than claims about a universal optimum, and each one sets a specific maximum width, a target frame rate, and a bits-per-pixel heuristic that drives the recorder bitrate. The preset limits the width of the output, not the height, because the source aspect ratio is preserved and the tool never enlarges a smaller source. Output dimensions are also rounded down to even pixel values for broader codec compatibility, so a 1279-pixel source under Balanced lands at width 1278 rather than 1280. The recorder bitrate is clamped between 180 kbps and 8 Mbps so that very low-motion sources do not collapse into a tiny file and very busy sources do not exceed an upper ceiling the browser can sustain in real time.
| Preset | Maximum output width | Target frame rate | Bitrate behavior |
|---|---|---|---|
| Small | 640 px | 24 fps | Bounded bits-per-pixel heuristic, clamped 180 kbps to 8 Mbps |
| Balanced | 1280 px | 30 fps | Bounded bits-per-pixel heuristic, clamped 180 kbps to 8 Mbps |
| Quality | 1920 px | 30 fps | Bounded bits-per-pixel heuristic, clamped 180 kbps to 8 Mbps |
These are the only three presets; there is no custom slider, no manual CRF input, and no per-field override. The output container is always WebM because browser MediaRecorder support for generated MP4 remains inconsistent, and the recorder tries VP9 first, then VP8, then generic WebM according to the current browser's reported support, so the same preset on the same source can produce slightly different bytes between browsers.
How to Compare Compression Approaches Locally
- Pick a representative source that is browser-decodable, no larger than 500 MiB, no longer than five minutes, and no more than 3840 × 2160 pixels of decoded area.
- Open the Video Compressor in a browser tab and select the file; the page validates extension or MIME, positive whole-byte size up to 500 MiB, decoded duration above zero and at most 300 seconds, each side at most 4096 pixels, and decoded area at most 3840 × 2160.
- Choose Small first and start compression, leaving the tab open while the source plays in real time. Encoding runs in real time because MediaRecorder observes the Canvas stream while the source plays, so a two-minute source takes approximately two minutes rather than completing instantly.
- When the job ends, record the reported output dimensions and the signed byte change, save the WebM as run-small, and immediately play the downloaded file fully before deleting anything.
- Choose the same source again, select Balanced, start a new run, save the WebM as run-balanced, and play it back to compare motion smoothness and detail against the Small result.
- Choose the same source a third time, select Quality, save the WebM as run-quality, and play it back the same way.
- Compare the three files by their actual byte sizes, their output dimensions, and your notes on visible artifacts, then keep the preset whose output meets your destination's size, picture, and sound requirements. Discard the other two only when the kept file has been played in full.
Why the Same Preset Produces Different Bytes Across Sources
Compression is content dependent, and the bounded bits-per-pixel heuristic the tool uses picks a recorder bitrate from resolution and frame rate, not from content. A low-motion animation may become much smaller than the source because the encoder can reuse prior frames efficiently; noisy footage, grain, camera shake, and rapidly changing detail carry more entropy and resist reuse, so the same preset can hold roughly the same bits per pixel but still produce a much larger file. A source that is already efficiently encoded with a modern codec can also produce an output of similar or larger size, because re-encoding through a Canvas at a fixed target cannot recover space the prior encoder already saved. The percentage shown is calculated only from the two actual Blob sizes, and the tool never labels a larger file as a reduction. Try another preset when the result does not suit your needs, and inspect the downloaded file before deleting the original.
Reading the Result: Bytes, Dimensions, and Percentage
After the source ends, the tool reports output dimensions, input and output bytes, and the measured percentage change, then offers the generated file for download. A negative percentage means the WebM is smaller than the source, a positive percentage means it is larger, and zero means the two blobs happen to match. Because the report comes from the two actual Blob sizes, the sign of the change is the most honest summary the page can give. You can extend the comparison with a checklist for inspecting the downloaded file so each preset's output is judged on dimensions, duration, picture, sound, and destination compatibility rather than on size alone.
Browser Limitations and When to Reach for FFmpeg
Audio is included only when the browser exposes a capturable track through HTMLMediaElement captureStream, and audio support varies by browser and source codec, so verify both picture and sound in the downloaded file. The tool does not normalize volume, mix tracks, remove metadata according to a certified standard, repair corrupt media, or preserve subtitles, chapters, attachments, rotation tags, color metadata, HDR signaling, or every container feature, and MediaRecorder will produce an error rather than a silent truncated file when something fails. 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 W3C MediaStream Recording specification and the MDN MediaRecorder reference describe the same browser APIs the page relies on.
Related reading: Video Compression: How to Know If You Actually Need It.