A video compressor test online means running one source file through a browser-based compressor, comparing the actual bytes in versus the actual bytes out, and reading the signed percentage change the tool computes from those two Blob sizes. The point of a test run is to verify two things on your own machine with your own footage: how much the file actually shrinks under a given preset, and whether the picture and sound survive the round-trip. Lizely's Video Compressor does this by decoding a browser-supported source, drawing each frame into a bounded Canvas, and recording that Canvas stream to WebM while the source plays in real time. When recording ends, the page reports the output dimensions, the input bytes, the output bytes, and the signed percentage change computed from those two Blob sizes — so the number you see is the actual change for your file, not a generic estimate. Because encoding runs in real time, a two-minute source takes about two minutes to finish, and the tab must stay open until the source has played to its end. Nothing about the source, the decoded frames, or the output leaves the current browser tab.
How a Video Compressor Test Actually Works
A test is not a target-size job. When you test a compressor, you are running a controlled experiment on one real source file: the same input goes in under different presets, and you watch how the output bytes, dimensions, and playback behavior change. The most useful tests run the same clip through two or three presets and compare the actual results side by side rather than trusting a preset description. Because every browser exposes a different WebM codec path, the same preset on the same source can produce a different file in Chrome, Firefox, or Safari — a test run in your actual browser is the only way to see what your audience would receive.
For a deeper background on how the re-encoding happens inside the page, the local re-encoding explainer walks through the Canvas + MediaRecorder path used here.
Limits That Gate the Test
Before a preset is even offered, the tool validates five hard limits on the file you pick. If any one fails, the test does not start and no download is offered.
- File extension or MIME type must look like a media file.
- Byte size must be positive and no greater than 500 MiB.
- Decoded duration must be greater than zero and no greater than 300 seconds.
- Each side of the decoded frame must be 4096 pixels or fewer.
- Decoded area must be no greater than 3840 × 2160 pixels.
These bounds exist to keep memory, Canvas allocation, and real-time playback predictable. The extension on a file name is only a hint: a file may be named MP4, WebM, MOV, M4V, or Ogg, but successful decoding still depends on the codecs installed in the current browser. A valid extension cannot make an unsupported codec decodable, and unsupported sources produce an error rather than a silent failure.
What Each Preset Changes During the Test
The three presets are explicit product choices rather than claims about a universal optimum. They differ in three concrete numbers: maximum output width, target frame rate, and the bits-per-pixel target that drives the requested recorder bitrate. All three preserve the source aspect ratio, never enlarge the source, and round the final output dimensions down to even pixel values for broader codec compatibility.
| Preset | Max width | Target frame rate | Behavior |
|---|---|---|---|
| Small | 640 px | 24 fps | Smallest footprint; suited to clips where motion and detail are modest. |
| Balanced | 1280 px | 30 fps | Middle ground for typical screen recordings and casual footage. |
| Quality | 1920 px | 30 fps | Largest bounded output; suited to footage with fine detail worth preserving. |
Under the hood, a bounded bits-per-pixel heuristic picks the requested bitrate, then clamps it into the 180 kbps to 8 Mbps range. The exact requested rate is not promised as the actual rate — the browser's WebM encoder makes the final call. Width is capped, not forced: a 720p source under the Quality preset still outputs at 1280 × 720 because enlargement is disabled.
Run the Test in Your Browser
The full test path is three steps on the page. Keep the tab focused until the source has finished playing.
- Choose a browser-decodable video no larger than 500 MiB, five minutes, or 3840 × 2160 pixels.
- Select Small, Balanced, or Quality and start compression; keep the tab open while the source plays in real time.
- Review the actual dimensions and byte change, download the WebM, and play it fully before deleting the original.
If you replace the file, change the preset, cancel, or navigate away mid-run, the active job is invalidated and the temporary Object URL is released. A two-minute source therefore takes roughly two minutes to finish — that is the cost of real-time Canvas recording rather than an offloaded batch job.
Reading the Numbers the Tool Reports
When the source ends, the page surfaces four concrete values: the output dimensions (after aspect-ratio preservation and even-pixel rounding), the input byte count, the output byte count, and a signed percentage change. The percentage is computed only from the two Blob sizes the test actually produced, so it is a measured result for your file rather than a marketing average. A negative percentage means the output is smaller than the source; a positive percentage means it is larger.
Worked example. Suppose you test a 50 MiB clip under the Balanced preset and the recorded Blob is 12 MiB. The signed change is (50 − 12) / 50 × 100 = 76% smaller, and the absolute saving is 50 MiB − 12 MiB = 38 MiB. The same clip under the Quality preset might come back at 21 MiB, which would be (50 − 21) / 50 × 100 = 58% smaller — a useful comparison that only this run on this machine can produce.
When the Output Comes Out Larger Than the Source
Compression is content dependent, and the tool does not pretend otherwise. A low-motion animation with flat color blocks may shrink dramatically under any preset. Noisy footage, heavy grain, fast camera shake, rapidly changing detail, or a source that is already encoded efficiently can come back at a similar size or even larger. When that happens, the page still reports the real bytes and the signed percentage — it never labels a larger file as a reduction.
If the first preset disappoints, try another. The three presets produce meaningfully different bitrate budgets, so moving from Quality down to Balanced or Small changes the requested rate enough to usually pull a stubborn result below the source. The trade-off is visible detail and frame rate, so the test you actually want is the one that compares all three on your real footage.
Verify Audio and Metadata Before Deleting the Original
A passing test is not complete until you have played the entire downloaded file. When the browser exposes an audio track through HTMLMediaElement captureStream, the tool adds that track to the output stream, but audio inclusion depends on the browser's capture path rather than on a guarantee. Subtitles, chapters, attachments, rotation tags, color metadata, and HDR signaling are not preserved — they fall outside what a Canvas + MediaRecorder re-encode can carry. The source plays audibly during real-time processing when it contains audio, so use device volume carefully if you do not want the room to hear it; muting the tab does not necessarily silence a captured track.
Verify picture, sound, duration, and playback in the destination app before deleting the original. For a quick read on whether browser-only processing is appropriate for your use case, the browser safety guide covers the data-flow questions that come up around testing.
When a Browser Test Is the Wrong Tool
A browser test is the right tool for casual distribution, screen-recording shrinkage, and quick checks on your own footage. It is the wrong tool when you need a deterministic, cross-platform master. The page does not normalize volume, mix tracks, repair corrupt media, or preserve container features that a Canvas pipeline cannot see. For archival masters, professional delivery specifications, exact codec profiles, two-pass rate control, fixed keyframe intervals, subtitle preservation, or deterministic output across machines, a maintained desktop encoder with a reviewed command line is the more honest path. The browser test answers "what does this preset do to my file on my machine"; the desktop encoder answers "what will every recipient see when they open my file."