The Video Compressor reports the output's exact pixel dimensions, the input and output byte counts, and a signed percentage change as soon as re-encoding finishes, so checking a result is a three-part inspection of the on-page report, the downloaded file's system properties, and a full playback test. Compression in this tool runs locally: the source video is decoded by the browser, each displayed frame is drawn into a bounded Canvas, and the Canvas stream is recorded with a WebM codec while the original plays in real time. Because encoding happens at playback speed, a two-minute source takes approximately two minutes, and the tool only stops reporting when the source video has finished playing through the Canvas. The numbers that appear after that stop are the only factual basis for whether the compression succeeded, which is why checking the result really means reading those numbers carefully, opening the downloaded file, and confirming both picture and audio before deleting the original.
What the Tool Reports When Compression Ends
When the source video finishes playing through the recording Canvas, the page surfaces a small block of verified facts. You will see the output resolution in pixels, the byte count of the original file, the byte count of the resulting WebM, and a single percentage value that compares those two numbers. Nothing is interpolated or estimated: each figure comes from a concrete measurement, and the percentage is calculated only from the two actual Blob sizes that exist in the tab. There is no promise that the result will be smaller, no rounding toward a marketing-friendly figure, and no silent padding added to make the output look like a reduction. If the reported percentage is positive, the new file is smaller than the input; if it is negative, the new file is larger. Both outcomes are honest descriptions of what the encoder produced.
How to Read the On-Page Size Change
The percentage uses a simple formula that is worth memorising: input bytes minus output bytes, divided by input bytes, then multiplied by 100. A positive value means the output is smaller than the input by that share of the original size; a negative value means the output is larger by that share. Because the sign is preserved, a value of -8.4% means the output is about 8.4% larger than the input, not that compression failed in some technical sense. The browser encoder, the source's motion and noise characteristics, the chosen preset's width and frame rate, and the requested bitrate all contribute to whether that sign ends up positive or negative. A low-motion animation can drop dramatically in size, while grainy footage, camera shake, or an already efficient codec can produce a similar or larger file. For a deeper look at how those reported numbers are produced and what they actually mean, see Video Compressor Accuracy: What It Actually Reports.
| Preset | Maximum width | Target frame rate | Bitrate range | Aspect behavior |
|---|---|---|---|---|
| Small | 640 px | 24 fps | 180 kbps – 8 Mbps | Preserved, never enlarged, even pixel rounding |
| Balanced | 1280 px | 30 fps | 180 kbps – 8 Mbps | Preserved, never enlarged, even pixel rounding |
| Quality | 1920 px | 30 fps | 180 kbps – 8 Mbps | Preserved, never enlarged, even pixel rounding |
Each preset chooses its width and frame rate, then a bounded bits-per-pixel heuristic chooses a target bitrate, which is clamped to the 180 kbps – 8 Mbps window before recording starts. The source aspect ratio is always preserved and the source is never enlarged, so a 1280 × 720 video under the Quality preset stays at 1280 × 720 rather than being upscaled to 1920 × 1080. Output dimensions are also rounded down to even pixel values for broader codec compatibility. Knowing which preset you selected is part of reading the result, because the same source under Small and Quality will report different dimensions, frame rates, and likely different sizes.
Verify the Downloaded File in Your System
The on-page report is only one of three checks. The second check is the downloaded file itself. Open your system file manager, right-click the WebM, and read the byte size shown in its properties or Get Info panel. Confirm the size matches the output bytes reported on the tool's results panel, because a mismatched value usually means the download did not complete. Right-click again and choose to open the file with your default media player or browser; if the player can decode VP9 or VP8 and report metadata, you will see the file's actual duration and pixel dimensions there. If those match the values the tool reported, the recording pipeline produced the file it claimed to. If they do not match, the file may have been corrupted in transit and should be re-downloaded or re-recorded. Cross-checking the same numbers in two independent places is the cheapest way to rule out a partial download or a stuck process.
What to Confirm in the Downloaded WebM
- File size in bytes equals the on-page output byte count.
- Duration matches the source's playback time, with finite duration reported by the player.
- Pixel dimensions match the on-page output resolution.
- Audio plays from start to finish, with no crackling, dropout, or sync drift.
- Picture plays from start to finish, with no green frames, freeze, or visible tearing.
Check Your Video Compression Result Step by Step
- Wait until the source finishes playing through the Canvas; do not close or refresh the page, because real-time encoding only finishes when the playback ends.
- Read the results panel: note the output dimensions, the input bytes, the output bytes, and the signed percentage change.
- If the percentage is negative or smaller than expected, do not panic; the size depends on motion, noise, source codec, browser encoder, and preset, so a larger file is a normal outcome for already efficient sources.
- Click the download button and save the WebM to a known folder, then verify the file's properties in your operating system show the same size as the on-page output byte count.
- Open the downloaded WebM in your default player or browser, and watch the full clip from beginning to end so you can confirm duration, picture quality, and audio behaviour match your destination's requirements.
- If anything is off, choose a different preset and re-run, because the source is still intact locally and a new run takes only as long as the source plays.
- Delete the original only after the downloaded WebM has been played in full and confirmed to meet your destination's size, duration, picture, sound, and compatibility requirements.
When the Output Is Larger Than the Original
A negative percentage is not an error. It usually means the source codec was already very efficient, the motion was high, the noise floor was high, or the chosen preset reserved more bits than the source actually needed. The tool does not label a larger file as a reduction, so the percentage can be trusted as a literal description. If the size matters more than the picture, switch to a smaller preset: moving from Quality to Balanced, or Balanced to Small, lowers the width and frame rate, which lowers the requested bitrate, which usually lowers the byte count. If the picture matters more than the size, keep the higher preset and accept that some sources compress very little. Either way, the result is whatever the encoder produced, and the report describes it without embellishment. The same MediaRecorder pipeline that powers WebM capture in browsers, documented on MDN at the MediaRecorder reference, has no concept of a guaranteed reduction, which is why the tool reports the actual bytes instead of an estimated saving.
Confirm Audio, Dimensions, and Playback Match the Destination
Compression here is container-aware but feature-narrow. Audio is included only when the current browser exposes a capturable audio track through HTMLMediaElement captureStream; the source plays audibly during real-time processing, so you may need device volume to hear it. Subtitles, chapters, attachments, rotation tags, color metadata, and HDR signaling are not preserved, so do not rely on them carrying over. The output container is always WebM because MediaRecorder support for browser-generated MP4 is inconsistent; the recorder tries VP9, then VP8, then generic WebM, so output can differ between browsers even with the same preset and source. For destinations that require MP4, exact codec profiles, two-pass rate control, fixed keyframe intervals, subtitle preservation, or deterministic cross-platform output, a maintained desktop encoder is the safer route, and the downloaded WebM should be checked inside the destination app before any cleanup. The Canvas-driven recording approach, captured from a playing source as described in the MDN HTMLCanvasElement.captureStream() reference, is the technical reason the output is a clean re-encode rather than a remuxed copy.
Privacy: What Stays on Your Device During the Check
Decode, Canvas drawing, MediaRecorder encoding, and download all happen in the current browser tab, which means the source bytes, decoded frames, and output bytes remain local for the entire check. No upload step occurs at any point, so verifying the result does not move the video off your device. Object URLs for the source and the output are revoked when the job is replaced, canceled, or unmounted, which means the temporary references are cleaned up as soon as you choose a new file, change presets, or leave the page. This matters when checking the result is part of a workflow involving private footage, work-in-progress drafts, or files covered by a non-disclosure agreement: the verification step does not introduce a separate server hop beyond what the page itself already does. Keeping the original on disk until the downloaded WebM has been verified in full is the final layer of that local-first check.
For a deeper look, see Avoid Mistakes in Video Compression: A Local Workflow.
For a deeper look, see How to Choose Balanced When Using Video Compression.