To compress video file size locally, pick a browser-decodable source up to 500 MiB, five minutes, or 3840 × 2160 pixels, choose one of three WebM re-encoding presets (Small, Balanced, or Quality), and let the in-browser pipeline transcode the file while it plays in real time. The original bytes never leave your device; the tool reads the file via the browser's local file API, re-encodes it against the selected preset, and shows you the actual output dimensions and the byte difference between the source and the result before you save anything. This approach is fast, private, and predictable because the same preset produces a comparable compression ratio on every run.
Most people land on this task for one of three reasons: an email attachment refuses to upload a 1.4 GB screen recording, a phone gallery is full of 4K clips that are sharper than the screen they will ever play on, or a presentation deck has hit its file-share ceiling. In all three cases the underlying problem is the same — the source codec was chosen for archival quality rather than for sharing. Re-encoding trades a small amount of detail for a much smaller container, and a bounded WebM output is usually the right destination because VP9 is widely supported, plays back in every modern browser, and gives consistent results across operating systems.
Why Files Get So Large in the First Place
Before deciding how to shrink a video, it helps to understand what is making it big. A modern smartphone can record a one-minute 4K clip at roughly 400 megabytes because the camera captures every frame at full resolution, applies a moderate amount of intra-frame compression, and saves the result in a container that adds metadata, audio tracks, and motion vectors. Multiply that by the number of minutes you record, and a vacation reel quickly blows past the 5 GB mark without any single clip feeling especially long.
Three variables drive almost every bloated video file: the resolution of each frame, the number of frames per second, and the bitrate the encoder is allowed to spend on each second of footage. Cutting any one of these three values has an outsized effect on the final size, which is exactly what re-encoding controls. A 1080p frame contains a quarter of the pixels of a 4K frame, so dropping resolution alone can shrink a file by 60 to 75 percent before any quality knob is touched.
The destination also matters. A slide deck rendered at 1280 × 720 cannot display the extra detail of a 4K master, no matter how clean the source. Storage archives and editing timelines benefit from higher bitrates because they survive multiple re-encodes; a one-shot share on a messaging app does not.
What the Three Presets Actually Do
The Video Compressor exposes three preset profiles instead of a confusing panel of bitrate sliders, because the relationship between quality and size is easier to reason about when there are only three choices. Each preset maps to a target bitrate range and a target resolution ceiling, so the output stays predictable no matter which source you feed it.
| Preset | Goal | Typical use case |
|---|---|---|
| Small | Lowest byte count; detail loss accepted | Email attachments, chat apps with upload caps, preview clips |
| Balanced | Noticeable shrink with little visible change | Social posts, internal demos, project portfolios |
| Quality | Modest shrink, near-original fidelity | Archival copies, client deliverables, second-generation backups |
Choosing a preset is a decision about how much detail you are willing to trade. A screen recording of a spreadsheet will tolerate aggressive compression far better than a drone shot of a sunset, because flat areas and text survive bitrate cuts while gradients and grain do not. Pick Small when the destination is a chat window, Balanced when the destination is a screen most viewers will see at normal size, and Quality when the destination is going to be projected, zoomed, or re-edited.
How Each Preset Behaves on Real Footage
The same preset produces noticeably different results depending on the source material, and a quick mental model prevents disappointment after a long encode. Highly compressible footage — talking heads against plain backgrounds, slide recordings, static product shots — handles every preset gracefully because most of the frame is a single colour. Cinematographic footage with motion blur, film grain, or handheld camera shake punishes aggressive presets, because the encoder has to spend bits on constantly changing detail.
A practical rule of thumb is to picture the viewer. If the watcher will see the video on a phone in vertical orientation with the chat panel open, they are looking at maybe two inches of screen for the active area, which is small enough that even the Small preset looks fine. If the watcher will see it projected on a conference room wall, the Quality preset is the safer choice because every flaw will be amplified.
Before You Start: Check These Source Limits
The compressor refuses inputs that would take too long to re-encode or that exceed what the browser can decode, so it is worth confirming your file falls inside the accepted envelope before you begin.
- File size: up to 500 MiB. Larger files should be trimmed first with the Video Trimmer or split into shorter sections.
- Duration: up to five minutes. Longer clips can be cut into segments and compressed individually.
- Resolution: up to 3840 × 2160 pixels (4K UHD). Anything above 4K should be downscaled with the Video Resizer first.
- Codec: must be browser-decodable. MP4 (H.264/AAC), WebM (VP8/VP9, Opus), and MOV (H.264) work in modern Chromium, Firefox, and Safari.
If your source fails any of these checks, the tool will surface the specific reason and the file will not start re-encoding. In that case, the right move is to use a companion tool first — trim the duration, resize the frame, or extract only the segment you actually need — and then return to the compressor with a file that fits.
Compress a Video File Step by Step
- Open the Video Compressor in a current desktop browser. The tool runs entirely on your device, so there is no account, upload queue, or sign-in step.
- Click the file picker and choose a video that fits the 500 MiB / five-minute / 3840 × 2160 envelope, or drag the file onto the drop target.
- Decide between Small, Balanced, and Quality. Small is the right pick for email and chat; Balanced for everyday sharing; Quality for near-original fidelity.
- Start the compression. The source plays in real time on the page while the in-browser encoder produces the WebM output in parallel. Keep the tab focused and visible until the job completes.
- Read the after-compression summary. The tool reports the actual output dimensions and the byte difference between the source and the result so you can confirm the shrink is real before saving.
- Download the WebM file, then play it back in full at its destination (chat client, slide deck, media player) before deleting the original. A full playback catches stutters, audio drift, or artefacts that a quick scrub can hide.
The "keep the tab open" instruction matters more than it sounds. Re-encoding is a sustained workload that browsers throttle or pause when a tab is hidden, which can stretch a two-minute job into twenty. If you must switch tabs, return to the compressor tab and confirm the progress indicator is still advancing before walking away.
Reading the Before-and-After Numbers
Once the job finishes, the tool shows two values worth paying attention to: the final output dimensions and the byte change. The dimensions tell you whether the preset downscaled your frame (for example, a 3840 × 2160 source compressed with Small often comes back as 1920 × 1080), which is by far the largest single driver of byte savings. The byte change tells you the absolute size reduction in megabytes or as a percentage of the original, so you can decide whether the output is small enough for its destination.
A useful sanity check: if your source is a screen recording and the byte change is less than 30 percent, the preset is probably not aggressive enough for an email attachment. If your source is a nature shot and the byte change exceeds 80 percent on the Balanced preset, expect to see banding in sky gradients — that is a signal to re-run the job on Quality.
Choosing Between the Three Output Sizes
Although each preset has a target ceiling, the actual output dimensions are chosen to match the source aspect ratio so the picture is never stretched or cropped. A 1920 × 1080 source stays 1920 × 1080 on Balanced and Quality, and only drops to a lower resolution on Small when the encoder decides the source has more detail than the destination needs. A vertically recorded 1080 × 1920 phone clip stays 1080 × 1920 instead of being padded into a 16:9 frame, which is why the byte change for portrait footage is usually slightly smaller than for landscape footage of equivalent quality.
If you need a specific output size for a known destination — for example, a 1280 × 720 master for an older media player — resize the file first with the Video Resizer and then compress the resized result on Quality. That two-step path produces a more consistent output than a single compression pass and lets you inspect the resized file before committing to the slower encode.
When Compression Is Not the Right Tool
Sometimes the real problem is not size but shape, and a compressor will only ever fight the symptoms. A 20-minute lecture you will never watch in full should be trimmed, not compressed. A 4:3 talking-head clip embedded in a 16:9 reel should be cropped to its real subject. A vertical phone video shot at 9:16 that needs to sit inside a square Instagram slot should be resized with an aspect-preserving fit, not re-encoded at the original frame.
The broader Lizely video toolkit covers each of these adjacent tasks without uploading the source, which is the point: every step happens on your device, and you only download a new file when you are happy with it. The cutting workflow handles trimming, the cropping workflow handles framing, and the resizing workflow handles aspect ratio — use whichever one fits the actual problem before reaching for compression.
Verify the Output Before Deleting the Original
The single biggest mistake people make with any local re-encoder is deleting the source before confirming the result plays cleanly end-to-end. Re-encoding can introduce stutter at scene cuts, drift between audio and video over long durations, or rare decoder incompatibilities in older media players. Watch the full WebM at its actual destination — whether that is a slide deck, a Slack thread, or a QuickTime window — before recycling the original file.
For longer clips or clips with heavy motion, it is also worth scrubbing a few seconds in from the start and a few seconds before the end. Codecs frequently place keyframes at regular intervals, and a glitch in the first or last segment usually means the rest of the file will misbehave for some players. If anything looks off, re-run the job on a higher preset or trim the problematic segment with the Video Trimmer first and compress the trimmed result.
Why Local Re-Encoding Beats Cloud Uploads for This Task
Cloud compressors ask you to upload the full file, wait for their servers to re-encode it, and download the result. That round trip can take longer than the re-encode itself, it costs the provider bandwidth they pass on through limits or ads, and it leaves a copy of your file on someone else's disk. Local re-encoding in the browser inverts the workflow: the source stays on your machine, the encoder runs at native speed on your CPU, and the only network traffic is the download of the smaller file you actually wanted in the first place.
For work-in-progress clips, unreleased screen recordings, and any video with sensitive content, the privacy argument alone is usually enough. For everything else, the speed argument wins — a five-minute 1080p clip re-encodes in roughly its own playback time on a recent laptop, which is faster than most upload links on a typical home connection.
Troubleshooting Common Outcomes
If the download link never appears, the most common cause is that the tab was backgrounded long enough for the browser to suspend the worker. Returning to the tab and starting a fresh job usually resolves it. If the output plays but the audio is missing, the source likely used a codec the browser could decode for video but not for audio; remuxing the source with a standard AAC track before compression restores sound. If the output is far smaller than expected and the picture looks blocky, the source resolution was probably higher than the destination needed and the Small preset downscaled aggressively, which is the intended behaviour rather than a bug.
When none of these apply, the next step is to trim the source down to a 30-second sample and run the compressor on the sample. A short test re-encodes in a few seconds and lets you confirm whether the preset, the browser, and the source codec are all agreeing with each other before you invest the full job.
For a deeper look, see Crop Video for Free Online with Pixel Accuracy.