Before you use video compression, compare the source file against the tool's hard input limits, the three preset profiles, the actual byte change the tool will report, and the destination requirements the output has to meet — because compression is content-dependent and the same preset can shrink one video while leaving another almost unchanged. The Video Compressor on Lizely re-encodes a single browser-decodable source into a WebM file locally, so the comparison you need to make is not between services but between what your source actually contains, what each preset caps it to, and what the recorded bytes look like after the run. The three questions that matter before you start are: does the source fit the limits, which preset matches your destination, and are you prepared to read the actual byte change rather than trust a promised percentage. Get those right and the rest is real-time playback in the tab.
What the Comparison Actually Decides
A short video with low motion and a clean background usually compresses aggressively; a noisy clip with camera shake, grain, or rapidly changing detail often resists compression, and an already efficient source can produce a WebM that is the same size or larger than the input. The Video Compressor does not promise a universal reduction. It draws the playing source into a bounded Canvas, captures that stream with whatever WebM codec the current browser supports, and reports the signed byte change between the input and the recorded Blob. That is why every comparison you make before compression has to be answered with the actual source in front of you, not with averages from someone else's clip.
The four comparisons that matter are: source against tool limits, preset against your destination, recorded bytes against your size budget, and recorded WebM against your playback target. If any one of those fails, you have a reason to re-run with a different preset, a different source, or a different tool — and Video Compressor is built to let you repeat those comparisons quickly because each run is local and each preset is a single click away.
Compare Your Source Against the Tool's Hard Input Limits
The first comparison is the most concrete: does the file you intend to compress meet the tool's documented boundaries? Anything outside those boundaries is rejected with an error and produces no download, so it is worth checking before you begin. The limits are listed below with the reason each one exists in the implementation.
| Input property | Documented limit | Why it matters |
|---|---|---|
| File extension or MIME | MP4, WebM, MOV, M4V, or Ogg | Extension alone does not guarantee decoding; the codec installed in the browser decides whether the file plays. |
| Positive byte size | Up to 500 MiB | Bounded so the source Blob can be loaded into memory without exhausting the tab. |
| Decoded duration | Above zero, at most 300 seconds | Real-time encoding means a two-minute source takes about two minutes; longer sources extend wall-clock time and memory. |
| Each side in pixels | At most 4096 pixels | Bounded so Canvas allocation stays predictable across browsers. |
| Decoded area | At most 3840 × 2160 pixels | Bounded so the working Canvas and MediaRecorder pipeline stay within tested ranges. |
If your source fails any row in that table, the comparison ends before encoding starts. A file can be named MP4 and still be rejected if the browser has no decoder for the codec inside it, because a valid extension cannot make an unsupported codec decodable. Codec support comes from the browser, so checking the actual playback in a tab before you commit to a preset is part of the comparison as well.
Compare What Each Preset Actually Changes
The second comparison is between the three named presets and your destination. Each preset is a transparent product choice rather than a claim about a universal optimum, and each one caps a different combination of width, frame rate, and target bitrate. Choosing between them is a comparison of trade-offs, not a search for the smallest file.
| Preset | Maximum output width | Target frame rate | Bitrate band | Typical fit |
|---|---|---|---|---|
| Small | 640 pixels | 24 fps | Clamped 180 kbps–8 Mbps by the bits-per-pixel heuristic | Quick sharing where the destination values byte count over resolution. |
| Balanced | 1280 pixels | 30 fps | Same clamp | General-purpose sharing, chat attachments, and screen recordings where 720p is enough. |
| Quality | 1920 pixels | 30 fps | Same clamp | Preview-quality output and cases where the destination plays back at full resolution. |
All three presets preserve the source aspect ratio, never enlarge the source, and round output dimensions down to even pixel values for broader codec compatibility. The requested bitrate is selected by a bounded bits-per-pixel heuristic and then clamped to 180 kbps through 8 Mbps before the recorder is configured, so the worst-case bitrate is the same across presets even though the per-frame pixel count differs. The recorder tries VP9, then VP8, then generic WebM according to the browser's reported support, so the same source and the same preset can produce a slightly different file in Chrome and Firefox. Comparing presets therefore means comparing what your destination actually plays, not what a comparison table promises.
How to Run the Side-by-Side Comparison in Video Compressor
The third comparison is procedural: run the file through the tool and inspect the actual result. Because each run is local, the only cost to running more than one preset is the wall-clock time of playback, which equals the source duration.
- Choose a browser-decodable video no larger than 500 MiB, five minutes, or 3840 × 2160 pixels of decoded area, and confirm the file plays in the current tab before you start.
- Select Small, Balanced, or Quality based on the destination comparison you made in the previous section, then start compression and keep the tab open while the source plays in real time.
- Wait for the recorder to stop at the end of playback, then read the reported output dimensions, the input bytes, the output bytes, and the signed percentage change in the result panel.
- Download the WebM and play it fully in a player that supports the codec the recorder chose; check picture, sound, and that the duration plays through to the end.
- If the result does not suit the destination, choose another preset and run the same source again — there is no upload step, so each run is a fresh local re-encode.
- Keep the original until the downloaded WebM has been played through and you have confirmed that size, duration, picture, sound, and compatibility meet the destination's requirements.
Encoding runs in real time because MediaRecorder observes the Canvas stream while the source plays, and the page draws at the preset cadence, tracks progress from source playback time, and stops stream tracks after recording. Choosing a new file, changing presets, canceling, or leaving the page invalidates the active job and releases temporary Object URLs, so a partial run cannot leak a half-finished file. Audio is included only when the browser exposes a capturable track through HTMLMediaElement captureStream, so muting the source may reduce what reaches the recorder depending on how the browser wires the track; if you need to verify sound, compare an audibly played download against a destination you trust rather than against the source's on-screen volume. The underlying mechanics are documented in the W3C MediaStream Recording specification and on the MDN MediaRecorder reference, with the Canvas side described under HTMLCanvasElement.captureStream().
Compare the Tool's Report Against What Your Destination Needs
The fourth comparison is interpretive. After the run, the tool reports the actual dimensions, the input bytes, the output bytes, and the signed percentage change between those two Blob sizes. That report is the only honest answer to the size question for this run, so it should be read against the destination rather than against an expectation. If the output is smaller and the destination accepts WebM, the run worked. If the output is the same size or larger, the run did not achieve what you wanted and a different preset, a different source, or a different tool is the next step — the tool never labels a larger file as a reduction, and the percentage shown is calculated only from the two actual Blob sizes. Compression is content-dependent: a low-motion animation may become much smaller, while noisy footage, grain, camera shake, rapidly changing detail, or an already efficient source can produce a similar or larger file. If you want a smaller result, change the preset and re-run; if you want a predictable result, you need a documented command-line encoder rather than a real-time browser pipeline. The companion guide Common Video Compression Mistakes and How to Avoid Them walks through several of the comparison traps in more depth, including the assumption that any single preset always wins.
When the Comparison Points You to a Desktop Encoder Instead
The final comparison is honest scope: a browser tool that records a Canvas stream in real time is not the right tool for every job. The Video Compressor does not normalize volume, mix tracks, remove metadata according to a certified standard, repair corrupt media, preserve subtitles, chapters, attachments, rotation tags, color metadata, HDR signaling, or every container feature. WebM is the only output container because MediaRecorder support for browser-generated MP4 remains inconsistent. Output can therefore differ between browsers even with the same preset and source, and the recorder will fall back from VP9 to VP8 to generic WebM depending on what the current browser reports. For archival masters, professional delivery specifications, exact codec profiles, two-pass rate control, fixed keyframe intervals, subtitle preservation, or deterministic cross-platform output, the right comparison is between this browser tool and a maintained desktop encoder such as FFmpeg with a reviewed command. None of those limitations are bugs; they are the boundaries of what a local browser pipeline can honestly promise, and comparing them honestly is what the question "what should I compare before I use video compression" is really asking.
If you're weighing options, What to Do When You Can't Use Video Compression covers this in detail.