Your video never leaves your device when you compress it with a browser-based, local WebM tool — every input byte, decoded frame, and output byte stays inside the current tab from start to finish. Decode, Canvas drawing, MediaRecorder encoding, and the final download all happen in the browser on your own machine. No file is uploaded to a server, no thumbnail is transmitted, no name or codec metadata is reported anywhere, and no result is stored remotely. The page plays the source video locally, draws each displayed frame into a bounded Canvas, records that Canvas stream with a WebM codec supplied by the current browser, and then offers the generated file for download. Only when you click download does anything leave the tab, and even then it travels directly from your device to your downloads folder. Lizely, the publisher of the local tool this article walks through, explicitly states it receives no video, no thumbnail, no duration, no file name, no codec, and no result. That contract is what separates a true local compressor from a typical online service.
How Browser-Based Video Compression Stays Local
Local compression depends on three browser APIs that are already shipped in Chromium, Firefox, and Safari, and the entire pipeline runs in a single tab without any network round trip. First, the page reads the chosen file with a URL.createObjectURL call, which produces a temporary in-memory reference that never leaves your machine. Second, an HTML5 video element plays the source in real time, and the browser's built-in decoder pulls each frame into memory locally. Third, the page calls HTMLCanvasElement.captureStream() to obtain a MediaStream from a Canvas, then hands that stream to a MediaRecorder configured for WebM. The MDN reference for HTMLCanvasElement.captureStream() documents the capture side, while the MDN reference for MediaRecorder documents the recording side. Both APIs describe the same contract this tool relies on.
Because the source plays at real time, encoding is also real time — a two-minute source therefore takes roughly two minutes to record, rather than completing in much less than real time. The page draws each frame at the preset cadence, tracks progress from source playback time, and stops stream tracks when the source ends. Replacing the file, changing the preset, cancelling, or closing the tab invalidates the active job and revokes the temporary Object URL. None of these steps touch a remote endpoint. The only network activity the tab performs is loading the static HTML, CSS, and JavaScript that drive the compressor itself.
Compress a Video Without It Leaving Your Device
The exact sequence below uses the Video Compressor, a local WebM re-encoder that follows the contract described above. Each step keeps the file inside your tab until you click the final download.
- Open Video Compressor in a current desktop browser and wait for the page to finish loading.
- Choose a browser-decodable video no larger than 500 MiB, no longer than five minutes, and no larger 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 your browser.
- Select Small to cap width at 640 pixels at 24 fps, Balanced to cap width at 1280 pixels at 30 fps, or Quality to cap width at 1920 pixels at 30 fps. Each preset preserves the source aspect ratio, never enlarges the source, and rounds output dimensions down to even pixel values.
- Press the start button and keep the tab open while the source plays in real time. The page draws each displayed frame into a bounded Canvas and records that stream with the WebM codec your browser supports — VP9 first, then VP8, then generic WebM.
- When the recording ends, review the reported output dimensions, input bytes, output bytes, and signed percentage change. The percentage is calculated only from the two actual Blob sizes and is never labelled a reduction when the output is larger.
- Click download to save the WebM to your downloads folder, then play the file in full to confirm size, duration, picture, and sound before deleting the original source.
If the result does not suit your needs, repeat the run with a different preset and compare the byte counts yourself. Compression is content dependent, so a low-motion animation may shrink dramatically while noisy footage, grain, or rapid camera shake can produce a similar or larger file — the tool reports both numbers honestly and never inflates the savings.
What the Tool Reports After Compression
Once the recorder stops, the page surfaces four concrete facts about your run, which are read directly from the in-memory objects rather than estimated. Output dimensions are the even-rounded pixel size actually written. Input bytes are the original Blob size of your chosen file. Output bytes are the Blob size of the WebM just recorded. The signed percentage change is calculated only from those two numbers — for example, an output that is two-thirds the size of the input shows a negative percentage, while an output that grew by ten percent shows a positive percentage. The page never claims a reduction when the file is actually larger. If you want to dig into how to interpret those numbers in practice, the Video Compressor Test Online: Inspect Real Results walkthrough covers a full comparison run with measured byte counts.
The requested bitrate is selected by a bounded bits-per-pixel heuristic and then clamped between 180 kbps and 8 Mbps. That heuristic is why a static slide deck compresses further than a fast sports clip, and why a high-motion source sometimes reaches the upper clamp even on the Small preset. None of the values shown after recording are sent anywhere; they exist only in the current tab and are cleared when you replace the file or close the page.
What the Three Presets Actually Do
The presets are transparent product choices rather than claims about a universal optimum. They differ in three disclosed dimensions: maximum output width, target frame rate, and the rough bits-per-pixel target that drives bitrate selection. The table below summarises what each one actually does, as defined by the tool's contract.
| Preset | Max output width | Target frame rate | Where the bitrate tends to land |
|---|---|---|---|
| Small | 640 px | 24 fps | Lowest, often near the 180 kbps floor |
| Balanced | 1280 px | 30 fps | Middle range, between the two clamps |
| Quality | 1920 px | 30 fps | Highest, can approach the 8 Mbps ceiling on busy footage |
All three presets preserve the source aspect ratio, never enlarge the source, and round output dimensions down to even pixel values so the encoded WebM is broadly compatible with decoders. None of them is a promise that the output will be smaller than the input; the byte counts shown after recording are the only honest comparison. Try another preset when the result does not suit your needs, and inspect the downloaded file before deleting the original.
When Online Compressors Do Upload Your File
Many sites that call themselves online video compressors actually upload your file to a remote server, transcode it on a CPU or GPU they control, store a copy for some period, and then send you a download link. That pipeline is convenient when the file is small and the connection is fast, but it has different privacy properties from a local tool: the file traverses their infrastructure, sits on their storage, and is subject to their retention policy. Some services auto-delete within an hour, others keep masters for days, and a few make the deletion timing opaque. If a site asks you to drag a 2 GB clip into the browser and then waits for a processing message while your connection stays busy, the bytes are almost certainly leaving your device.
A quick way to tell the difference is to open the browser's developer tools, watch the Network panel during compression, and look for any request whose body or response carries your video data. A local tool will typically show only static asset requests for the page itself. That test is enough to separate true browser-based re-encoding from a thin upload-and-convert wrapper. If you specifically want a privacy-first path that never uploads, the Compress a Video to 50 MB Without Uploading It guide walks through the same local tool with a concrete size target in mind.
Honest Limits of Local WebM Re-Encoding
Local compression is not a substitute for a maintained desktop encoder when you need archival masters, deterministic cross-platform output, two-pass rate control, fixed keyframe intervals, subtitle preservation, or exact codec profiles. The tool documented here explicitly does not normalize volume, mix tracks, repair corrupt media, or preserve subtitles, chapters, attachments, rotation tags, colour metadata, or HDR signalling. WebM is the only output container because MediaRecorder support for browser-generated MP4 remains inconsistent across browsers, and the recorder tries VP9, then VP8, then generic WebM based on the current browser's reported support — so the same source can produce slightly different output between Chrome, Firefox, and Safari even with the same preset.
Input is bounded by four hard limits that protect memory and Canvas allocation: 500 MiB maximum file size, five minutes maximum duration, 4096 pixels on either side, and 3840 × 2160 pixels maximum decoded area. Audio is included only when the browser exposes a capturable audio track through the source element's captureStream, and the source plays audibly during real-time processing when it contains audio. Invalid files, unsupported decoders, over-limit duration, over-limit frames, missing Canvas streams, or unavailable WebM recorders all produce an explicit error and no download. None of those limits change the privacy answer: every failure mode leaves the file on your device. Keep the original until you have played the complete output and confirmed that size, duration, picture, sound, and compatibility meet the destination's requirements.