Video compressor accuracy is whatever the tool measures and reports after a job finishes, not the size label printed next to a preset button. A trustworthy compressor shows you the real input bytes, real output bytes, the actual output dimensions, and whether audio made it into the file — and lets you verify the result before you delete the original. The Video Compressor follows that contract: it re-encodes a browser-decodable video into WebM inside the current tab, plays the source in real time, and prints the measured percentage change from the two actual Blob sizes. Accuracy here means transparency about what actually happened, not a guaranteed reduction.
If you have ever loaded a clip into a web tool, watched a "compressed" file finish, and then opened the download only to find it was the same size — or larger — you already know why accuracy is a measurement question rather than a marketing question. A real percentage change comes from comparing two specific files in the same session. Everything below explains what the Video Compressor records, why a "smaller" result is content-dependent, and how to verify the output before you commit to it.
What "Accuracy" Means for a Video Compressor
In video compression, accuracy is the difference between what a tool claims and what it actually delivers. The measurable parts of that claim are well-defined: the output file size in bytes, the output resolution in pixels, the output duration in seconds, and whether the audio track was captured. Anything a tool cannot measure — for example "this preset looks great" — is opinion, not accuracy. The Video Compressor treats accuracy as a reporting problem: after each run it lists the dimensions the Canvas drew at, the bytes the recorder produced, and the signed percentage change between those bytes and the source file the browser actually decoded.
Three details follow from that definition. First, accuracy is per-run, not per-preset — two clips run through "Balanced" can land at very different sizes because their motion, grain, and codec history differ. Second, accuracy includes negative results: when the output Blob is bigger than the input, the tool still reports the real percentage and never relabels a growth as a reduction. Third, accuracy is local — there is no server log to compare against, because the decode, Canvas draw, MediaRecorder encode, and download all happen inside the same tab. That is also why the source, decoded frames, and output never leave the device.
What the Video Compressor Reports After a Run
When the source playback ends, the page reads the finished recording as a Blob and computes the difference against the input Blob you chose. The report shows three pieces of information you can act on:
- Output dimensions — the rounded-down, even-pixel width and height the Canvas used during recording. These come from the preset's maximum width, the source aspect ratio, and the rule that the tool never enlarges.
- Input and output bytes — the actual size in bytes of each Blob, not a rounded estimate. The signed difference is the percentage shown next to the download button.
- Audio presence — whether the browser exposed a capturable audio track through the source element. If it did, that track was added to the recorded stream; if it did not, the file is video-only.
None of these numbers are smoothed or adjusted to look better. A larger output is reported with the same reporting as a smaller one — the measured percentage change reflects the actual Blob sizes. That is the core of the accuracy contract: measured in, measured out, signed change, download the Blob.
Preset Limits and the Bounded Bitrate Range
The three presets are explicit, bounded product choices rather than universal "best" labels. They set a maximum output width, a target frame rate, and a video bitrate that the bounded bits-per-pixel heuristic picks, clamped between 180 kbps and 8 Mbps. The table below records the published limits; actual output bytes still depend on the content and on the browser's MediaRecorder implementation.
| Preset | Max output width | Target frame rate | Bitrate range | Aspect handling |
|---|---|---|---|---|
| Small | 640 px | 24 fps | 180 kbps – 8 Mbps (content-set) | Preserved, never enlarged, even pixels |
| Balanced | 1280 px | 30 fps | 180 kbps – 8 Mbps (content-set) | Preserved, never enlarged, even pixels |
| Quality | 1920 px | 30 fps | 180 kbps – 8 Mbps (content-set) | Preserved, never enlarged, even pixels |
The width cap matters because it bounds memory and Canvas allocation. The frame-rate target matters because MediaRecorder observes the Canvas stream while the source plays — drawing and recording happen at the chosen cadence, not faster. The bits-per-pixel heuristic matters because it links bitrate to the resolved output size, so a 640 × 360 Small run receives a different budget than a 1920 × 1080 Quality run. The 180 kbps floor and 8 Mbps ceiling bound the requested recorder bitrate.
Why the Output Can Be Larger Than the Source
The percentage shown is calculated only from the two actual Blob sizes. The tool never claims every result will be smaller, and several content patterns reliably grow the file:
- Low-motion animation or already-efficient sources — if the input was encoded with a slow preset at a tight bitrate, re-encoding at the same effective budget can produce a similar or larger WebM.
- Noise, film grain, and sensor noise — random high-frequency detail costs bits in any codec; a VP9 or VP8 pass through MediaRecorder may not compress it as tightly as the original encoder did.
- Camera shake and rapidly changing detail — high-motion frames need more bits, and the real-time recorder cannot run multi-pass analysis to spend them efficiently.
- Browser encoder differences — the recorder tries VP9, then VP8, then generic WebM according to the browser's reported support. Output bytes can therefore differ between Chrome, Firefox, and Safari even with the same preset and source.
The honest rule: if the percentage is positive, the new file is bigger than the source. Try a tighter preset, accept that the destination tolerates the result, or send the file through a maintained desktop encoder that supports two-pass rate control.
How to Compress and Verify the Result
- Open Video Compressor and choose a browser-decodable video. The file must be no larger than 500 MiB, no longer than five minutes, with each side at most 4096 pixels and a decoded area at most 3840 × 2160 pixels.
- Select Small, Balanced, or Quality. Each preset sets a maximum output width, a frame-rate target, and a bounded bits-per-pixel budget — none of them enlarge the source or distort the aspect ratio.
- Click start and keep the tab open. The page plays the source in real time, draws each displayed frame into a Canvas, and records that Canvas stream with the first supported WebM MIME the browser reports through the MediaRecorder API. A two-minute source therefore takes roughly two minutes rather than completing instantly.
- Watch the percentage change. It is the signed difference between the input and output Blob sizes — minus if the new file is smaller, plus if it is larger. Neither result is silently relabelled.
- Download the WebM and play it fully before deleting the original. Confirm picture, sound, duration, and that the file opens in the application you plan to use next.
If the first preset does not suit your destination, run the same source through a different preset. Nothing about the previous run is reused, and any temporary Object URLs are revoked when you choose a new file, change presets, cancel, or leave the page.
Limits That Affect Accuracy
Some failures are visible, some are silent in a web-only compressor. The Video Compressor surfaces the visible ones: an invalid file, an unsupported decoder, an over-limit duration, an over-limit frame, a missing Canvas stream, or an unavailable WebM MIME each produces an error and no download. Nothing is silently truncated to make a result fit. The less visible ones are codec and browser dependencies:
- Decoding depends on the browser. A file extension such as .mp4 or .mov is not a guarantee — successful decode still depends on the codecs installed in the current browser. A valid extension cannot make an unsupported codec decodable.
- Recording depends on MediaRecorder support. The tool records the Canvas stream using the first MIME the browser reports among VP9, VP8, and generic WebM. Different browsers produce different bytes even on the same source and preset.
- Audio capture is conditional. When the source exposes a capturable audio track through the source element, the tool adds it to the recorded stream; otherwise the output is video-only. The source plays audibly during real-time processing, so use device volume and verify both picture and sound in the download.
- Container features are not preserved. Subtitles, chapters, attachments, rotation tags, color metadata, HDR signaling, and many container-specific fields are not carried into the WebM output. WebM is the only container because browser MediaRecorder support for generated MP4 remains inconsistent.
When a Desktop Encoder Is More Accurate
The Video Compressor is a local browser utility, not an archival tool. For deterministic, cross-platform output, exact codec profiles, two-pass rate control, fixed keyframe intervals, subtitle preservation, or a master you can re-encode months later and reproduce byte-for-byte, use a maintained desktop encoder such as FFmpeg with a reviewed command. The MediaRecorder pipeline that the Video Compressor relies on cannot offer those guarantees, and the percentage shown on screen is a measurement of that specific run rather than a promise about the next one.
That is also why the original is worth keeping until you have played the complete output and confirmed that size, duration, picture, sound, and compatibility meet the destination's requirements. Accuracy is verified, not assumed — and verification happens after the file is on disk, in the application you actually plan to use.