Video compression normally produces a smaller WebM file at a lower width, a defined frame rate, and a bounded bitrate, but the size change is always reported as actual bytes rather than as a guaranteed reduction. When a browser-decodable source is re-encoded locally through the Video Compressor, the page draws each displayed frame into a Canvas at the chosen preset's maximum width, records that stream with whatever WebM codec the current browser exposes, and then shows you the output's pixel dimensions, the input and output bytes, and the signed percentage change. The preset you choose sets a hard ceiling on width and a target frame rate, never enlarges the source, and rounds dimensions down to even values for codec compatibility. Bitrate is chosen from a bits-per-pixel heuristic and clamped to a fixed range between 180 kbps and 8 Mbps. None of those numbers is a promise that the output will be smaller than the source.
How File Size Changes After Video Compression
The percentage the tool shows is calculated only from the two actual Blob sizes, which means it always reflects the real byte change regardless of direction. Compression is content dependent: a low-motion animation may become much smaller because neighboring frames look similar, while noisy footage, heavy grain, or rapid camera shake can resist compression and produce an output similar to or larger than the input. The tool does not promise that every result is smaller, and it does not label a larger file as a reduction. The signed number you see, whether negative for a reduction or positive for growth, is the measured delta between source bytes and output bytes. There is no hidden rounding to a marketing-friendly figure and no comparison to a hypothetical ideal file size.
Because the tool works in real time while the source plays, the bitrate it asks the browser's MediaRecorder for comes from a bounded bits-per-pixel heuristic that is clamped between 180 kbps and 8 Mbps. If the chosen preset would require more than 8 Mbps at the target resolution and frame rate, the tool does not exceed that ceiling. If the heuristic falls below 180 kbps, it is raised to that floor. Either way, the ceiling and floor exist so the output stays inside a range where the resulting WebM is broadly playable and the file size change stays predictable. According to the MDN documentation for MediaRecorder, the codec and bitrate that a browser actually applies to a Canvas stream are not identical across browsers, which is part of why two different browsers running the same source through the same preset can still produce different sizes.
You should treat the displayed percentage as a measurement, not a guarantee. The tool shows the actual numbers so you can decide whether the change matches your goal before downloading or deleting anything. If the result is not what you expected, the right next step is to try another preset on the same source and compare the new numbers to your target, rather than to assume the first attempt is final.
What Resolution and Frame Rate to Expect From Each Preset
Each preset is a transparent product choice rather than a claim about a universal optimum. The three settings differ in maximum output width and target frame rate, and they all preserve the source aspect ratio without enlarging it. Dimensions are rounded down to even pixel values so the resulting WebM is compatible with a wider range of decoders. The preset you choose is the only thing that varies on the encoder's side; everything else, including the bits-per-pixel heuristic and the bitrate clamp, stays constant.
| Preset | Maximum output width | Target frame rate | Aspect handling | Typical use |
|---|---|---|---|---|
| Small | 640 px | 24 fps | Preserved, never enlarged | Quick previews, low-bandwidth sharing |
| Balanced | 1280 px | 30 fps | Preserved, never enlarged | General sharing, screen recordings, tutorials |
| Quality | 1920 px | 30 fps | Preserved, never enlarged | Higher-detail playback where size matters less |
No preset upscales your video. If your source is already narrower than the preset's maximum width, the output keeps that narrower width. If your source is taller than the matching height for the chosen width at the source aspect ratio, the output keeps the matching height and the width is reduced to preserve proportions. The tool does not stretch, letterbox, or pillarbox, and it does not add black bars. Widths and heights are both rounded down to even pixel values so the codec accepts the frame without complaint.
The bitrate follows from the preset's resolution and frame rate using the bounded bits-per-pixel heuristic. Because that heuristic is clamped between 180 kbps and 8 Mbps, very small outputs still receive enough bits to stay watchable, and very large outputs do not exceed the cap that would balloon the file. The output's actual measured bytes are reported after recording finishes, so the bitrate and the final file size are not the same number, even though the bitrate heavily influences the size.
How to Compress a Video Locally Step by Step
- Pick a browser-decodable video no larger than 500 MiB, five minutes, with each side up to 4096 pixels, and no more than 3840 × 2160 pixels of decoded area. Files 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.
- Select Small, Balanced, or Quality and start compression. Keep 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.
- Review the actual output dimensions and the signed byte change the tool reports when recording finishes. The percentage is calculated from the two actual Blob sizes, never from a target or a guess, so a positive number means the output is larger than the input.
- Download the resulting WebM and play the file fully before deleting the original. Verify picture and sound, duration, and compatibility with the destination where you intend to use it.
If the result does not suit your needs, try a different preset on the same source. If decoding fails because of an unsupported codec, an over-limit duration, an over-limit frame, a missing Canvas stream, or an unavailable WebM recorder, the tool returns an error and produces no download rather than silently truncating the work. Choosing a new file, changing presets, canceling, or leaving the page invalidates the active job and releases any temporary Object URLs. The page draws at the preset cadence, tracks progress from source playback time, and stops stream tracks after recording, so canceling mid-way is safe.
Why the Output Can Sometimes Match or Exceed the Source
An already efficient source can produce a similar or larger file after re-encoding because the original codec was already doing a good job and the new WebM encoding cannot beat it on every frame. Codecs differ in how they handle motion estimation, prediction, and entropy coding, and the bitrate the tool requests may be higher than the bitrate the source actually needed for the same visible content. A long still frame encoded with VP9 at the heuristic's chosen bitrate will be larger than the same still frame encoded with a more efficient source codec at a lower bitrate. The output's measured byte count is the honest answer in each case.
Noisy footage makes the situation worse. Film grain, sensor noise, and high-frequency detail such as tree branches against a bright sky cost bits to encode, and the bits-per-pixel heuristic does not know in advance how compressible your content is. A handheld clip with rapid camera shake looks dramatically different from frame to frame, so the codec spends more bits on motion vectors and residuals. None of that is a defect in the tool; it is the natural consequence of asking a single-pass real-time encoder for a fixed bits-per-pixel budget on content that resists it.
The tool never relabels a larger file as a smaller one. If you need a guaranteed reduction toward a specific target size, use a maintained desktop encoder with a reviewed two-pass command rather than a one-shot browser heuristic. The Video Compressor is built for local, single-shot exploration of what re-encoding actually produces, not for hitting a contractual delivery size. For a closer look at how that measurement interacts with real-world content, the guide on Video Compressor accuracy and what it actually reports walks through the same signed-percentage idea with concrete examples.
What the Output WebM Will and Will Not Preserve
The output is always WebM because MediaRecorder support for browser-generated MP4 remains inconsistent across browsers. The recorder tries VP9 first, then VP8, then generic WebM according to the current browser's reported support, so the same source can produce different files in different browsers at the same preset. Audio is included only when the browser exposes a capturable audio track through the source element's captureStream; if no track is exposed, the output has no audio and you will need to verify that yourself before relying on it for playback. As MDN explains for HTMLCanvasElement.captureStream(), the audio track has to come from a capturable media element, not from the Canvas itself.
Subtitles, chapters, attachments, rotation tags, color metadata, HDR signaling, and many other container features are not preserved. The tool does not normalize volume, mix tracks, remove metadata according to a certified standard, repair corrupt media, or preserve every container feature. The page draws at the preset's cadence, tracks progress from source playback time, and stops stream tracks after recording, but the encoded file is a fresh WebM with the dimensions, frame rate, and bitrate the recorder produced. If your destination relies on a chapter marker, a subtitle track, or a color profile, those will need to be added back through a separate workflow.
This utility also does not run two-pass rate control, enforce fixed keyframe intervals, or target deterministic cross-platform output. For archival masters, professional delivery specifications, exact codec profiles, subtitle preservation, or any workflow where the file must match a spec byte-for-byte across machines, use a maintained desktop encoder with a reviewed command. For sharing, previews, and quick local exploration, the trade-offs are deliberate rather than accidental.
Verifying the Result Before Deleting the Original
Two checks matter before you commit to the new file: play the entire download in a player you trust, and compare the output bytes to the source bytes honestly. The signed percentage change is a measurement, and the only way to confirm that the visual quality matches your goal is to watch the output end-to-end. Browser support and codec combinations vary, so verifying both picture and sound in the downloaded file is part of the workflow, not an extra step.
Source bytes, decoded frames, and output bytes all remain in the current tab. Lizely receives no video, thumbnail, duration, file name, codec, or result, which means the only place the file exists is in your downloads folder and on your disk. Keep the original until you have played the complete output and confirmed that size, duration, picture, sound, and compatibility meet the destination's requirements. If you want to plan the workflow before starting, the guide on how to choose the right approach for video compression walks through decision points that affect which preset to pick and what expectations to set in advance.