Before you use video compression, the most important things to know are which inputs the tool accepts, what limits apply to file size, duration, and resolution, what trade-offs each preset makes, and whether the output preserves audio, metadata, and other features from the source. A browser-based local compressor like Video Compressor runs entirely in your current tab, so the decisions you make before clicking Start determine everything that follows. You will need a video the browser can actually decode (a valid extension is not the same as codec support), a file inside the 500 MiB, five-minute, and 3840 × 2160 pixel caps, and a realistic expectation that compression is content dependent — not every run produces a smaller file. Knowing these facts in advance prevents wasted runs, prevents disappointment when a preset does not shrink a noisy clip, and prevents surprises when the output WebM drops subtitles, color tags, or rotation flags the source carried.
Input Limits and Format Requirements
Before you open Video Compressor, confirm that your source file sits inside the documented caps. The browser decodes the video locally, so the tool checks four limits up front:
- File size: positive whole byte size, no larger than 500 MiB.
- Duration: at least one frame and at most 300 seconds (five minutes).
- Decoded frame size: no more than 4096 pixels on either side.
- Decoded area: no more than 3840 × 2160 pixels total.
These caps exist to bound memory, Canvas allocation, and the real-time work that follows. A valid container extension such as MP4, WebM, MOV, M4V, or Ogg is necessary but not sufficient — the file still has to be decodable by the codecs installed in the current browser. A long-standing point of confusion is that a recognizable file name cannot rescue an unsupported codec; renaming or rewrapping does not install the missing decoder. If your file fails to load even though the extension looks right, the issue is usually the codec, not the tool.
For a closer look at why the 500 MiB cap is structured the way it is, the guide on what the 500 MiB limit means in video compression walks through the memory math and the practical ceiling for everyday clips.
The Three Presets and What They Actually Do
Video Compressor exposes three presets — Small, Balanced, and Quality — that map to concrete pixel, frame-rate, and bitrate choices. None of them is a guarantee; each is a transparent product choice rather than a claim about a universal optimum.
| Preset | Max output width | Target frame rate | Typical use |
|---|---|---|---|
| Small | 640 px (height derived from source aspect ratio) | 24 fps | Email attachments, quick previews, low-bandwidth sharing |
| Balanced | 1280 px | 30 fps | Most everyday clips, social-style playback on desktop and mobile |
| Quality | 1920 px | 30 fps | Larger screens, second-tier archival when a master already exists |
All three presets preserve the source aspect ratio and never enlarge the source. Output dimensions are rounded down to even pixel values for broader decoder support. The bitrate used for each preset is chosen by a bounded bits-per-pixel heuristic, then clamped into a range of 180 kbps through 8 Mbps, so very wide, very high frame-rate sources still land inside that corridor.
Choosing a preset is partly about taste, but the rules of thumb below help most runs:
- Start with Balanced if you are not sure — 1280 px at 30 fps sits in the middle of the bitrate corridor and rarely produces surprises.
- Pick Small when bandwidth, upload caps, or attachment size limits dominate the goal.
- Pick Quality only when the destination player supports WebM at 1920 px / 30 fps and you have already accepted that compression is still lossy.
For a deeper discussion of how preset choices map to results, see how to choose quality when compressing a video.
How to Compress a Video Locally in Your Browser
The full local workflow below is the one to follow when you are ready to produce a WebM file without uploading the source.
- Open Video Compressor in a browser tab and choose a source file that meets the 500 MiB, five-minute, and 3840 × 2160 caps described above.
- Select Small, Balanced, or Quality based on the destination you are aiming for; the preset determines max width, target frame rate, and the bitrate corridor for the run.
- Start compression and keep the tab open. The source plays locally, and the tool draws each displayed frame into a bounded Canvas, then records the Canvas stream with a WebM codec the current browser reports.
- When the source ends, read the actual dimensions, the input bytes, the output bytes, and the measured percentage change. The displayed percentage is calculated from the two real Blob sizes — not from a target.
- Download the WebM and play it fully in a player you trust before deleting the original. Confirm picture, sound, duration, and size match the destination's expectations.
- If the result does not fit the destination, try a different preset and re-run on the same source. Compression is content dependent, and a preset that shrinks one clip may grow another.
Real-Time Processing and How Long to Expect
Encoding runs in real time because MediaRecorder observes the Canvas stream while the source plays. A two-minute source therefore takes approximately two minutes, not the milliseconds a desktop encoder might return on a fast CPU. The page draws frames at the preset cadence, tracks progress from source playback time, and stops stream tracks after recording ends. The browser implementation behind this pipeline is described in the MDN MediaRecorder reference.
During the run the source plays audibly when it contains audio, so be ready for the speaker to broadcast your video for the duration of processing. Use device volume to manage the output. Muting the page does not necessarily silence a captured audio track, so verify sound in the downloaded file rather than assuming it was dropped. If you replace the file, switch presets, cancel, or close the tab, the active job is invalidated and temporary Object URLs are released — no orphan data lingers in the tab.
What the Output Will and Will Not Keep
A useful way to plan around the output is to separate what is preserved from what is dropped, because most surprises after a run come from missing metadata rather than missing pixels.
| Source feature | Handled by Video Compressor |
|---|---|
| Picture frames, drawn into a bounded Canvas | Preserved — re-encoded at the preset's width and frame rate |
| Aspect ratio | Preserved — never enlarged |
| Audio track | Included only when the browser exposes a capturable track through HTMLMediaElement captureStream |
| Subtitles, chapters, attachments | Not preserved |
| Rotation tags, color metadata, HDR signaling | Not preserved |
| Source codec, source container | Output is WebM only; the recorder tries VP9, then VP8, then generic WebM |
| Source file name and original metadata | Not preserved |
The tool also does not normalize volume, mix tracks, repair corrupt media, or preserve every container feature. Output can differ between browsers even with the same preset and source, because VP9, VP8, and generic WebM produce different bitstreams. Treat the downloaded WebM as a fresh encode, not a wrapper around the original bytes. If the destination requires MP4, exact codec profiles, two-pass rate control, fixed keyframe intervals, subtitle preservation, or deterministic cross-platform output, route the work to a maintained desktop encoder such as FFmpeg with a reviewed command.
Privacy and Local Processing
Decode, Canvas drawing, MediaRecorder encoding, and download all happen in the current browser tab. Lizely receives no video, no thumbnail, no duration, no file name, no codec, and no result. There is no upload step in the pipeline, which is also why the limits exist — the work has to fit in the tab's memory rather than on a remote server. Closing the tab, starting a new file, or refreshing ends the session and frees any temporary data.
The percentage shown next to the result is calculated only from the two actual Blob sizes. The tool does not label a larger file as a reduction, and it does not promise that every result is smaller. Compression is content dependent, so 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. Plan to inspect the downloaded file with your own player before treating the run as final.
When a Browser Compressor Is Not the Right Tool
Local browser compression trades depth for convenience. It will not give you an archival master, will not match a professional delivery spec, and will not produce deterministic files across machines. Specific gaps worth naming:
- Exact codec profiles, two-pass rate control, and fixed keyframe intervals are not exposed.
- Subtitle preservation, chapter markers, attachments, and most color or HDR metadata are not carried through.
- Browser MediaRecorder support for generated MP4 remains inconsistent, so WebM is the only output container.
- Real-time encoding means a five-minute source takes about five minutes to process, not seconds.
For archival masters, professional delivery, or any workflow that needs deterministic cross-platform output, use a maintained desktop encoder with a reviewed command. For everyday sharing, quick previews, email-friendly WebMs, and any situation where keeping the source on your device matters, a browser-based run through Video Compressor is the right starting point.
Verify the Result Before Deleting the Original
Keep the original until you have played the complete output and confirmed size, duration, picture, sound, and compatibility with the destination. The single most common cause of regret after compression is deleting the source before noticing that a track was dropped, that the WebM container is rejected by an older player, or that the percentage change looked good but the bitrate was lower than the destination expects. Verification is part of the workflow, not an optional extra.
For example, if your source is 48 MiB and the output is 12 MiB, the displayed change is calculated as (12 − 48) ÷ 48 × 100 = −75.0%, so the tool reports a 75.0% reduction. The numbers come straight from the two Blob sizes the browser produced — there is no smoothing or rounding to a marketing figure.
A simple three-step verification on every run:
- Open the downloaded WebM in your usual player and watch at least thirty seconds past any fast-motion scene.
- Confirm the audio plays through, including any transitions, and that duration matches the source within a frame or two.
- Check that the byte count makes sense relative to the original, and that the destination accepts the file format before you delete anything.
With those checks in place, a browser-based compressor handles the routine work of producing a smaller WebM without sending your video anywhere. That is the central trade-off the tool asks you to accept in advance — and knowing it before you click Start is what separates a successful run from a wasted one.