How to Compress a Video Without Losing Quality (MP4, WebM and MOV)

The four levers that decide a video's file size (use them in this order)

Every MP4, WebM or MOV is the sum of a video stream and (usually) an audio stream. The video stream eats the overwhelming majority of the bytes, and it is controlled by four variables. Change them in the wrong order and you destroy quality for nothing.

1. Bitrate (the encoder's budget). Bits per second of video. This is the single most direct control: halve the video bitrate and, all else equal, the video portion roughly halves. Lower it too far and you get blocky artefacts in motion and mushy detail in foliage, water and crowds.

2. Pixel dimensions. A 4K frame has four times the pixels of 1080p, so it needs about four times the bitrate to look the same. If your destination is a phone or a web page, you almost never need 4K — resizing down is the cheapest, cleanest size cut there is.

3. Frame rate. 60 fps is twice the frames of 30 fps, so it costs more for the same quality. For talking heads, screen recordings and static scenes, dropping 60 to 30 fps saves a lot and is rarely noticed.

4. Codec. How cleverly the frames are squeezed. A modern codec (VP9, AV1, H.265) can encode the same picture 30-50 percent smaller than H.264 — but with compatibility and speed trade-offs (see below).

The practical order is therefore: resize until the dimensions match the destination, drop the frame rate if it is needlessly high, then walk the bitrate down to the lowest value that still looks clean. Audio is a rounding error by comparison (128 kbps audio on an 8 Mbps video is under 2 percent) — but if the clip has no speech, removing the audio track saves that little bit and one less stream to sync.

Predict the size before you encode: bitrate × duration

The most useful thing about video is that the output size is almost fully determined before a single frame is processed. The maths is one line:

Size (MB) ≈ ( total bitrate in kbps ÷ 8 ) × duration in seconds ÷ 1000.

So a 60-second clip at 6,000 kbps video + 128 kbps audio: ( (6000 + 128) ÷ 8 ) × 60 ÷ 1000 ≈ 46 MB. Double the bitrate and you double the file; double the length and you double it. This is why "compress my two-hour 4K video to 1 MB" is impossible — the duration is fighting you, not the settings.

Flip the formula to hit a target size: bitrate ≈ ( target MB × 8 × 1000 ) ÷ seconds. For a 16 MB limit on a 30-second clip, that is about 4,200 kbps total. Aim slightly under so a strict cap still passes.

One caveat the browser tool makes very visible: because it re-encodes at a target bitrate, a short clip that is already heavily compressed can come back larger than it went in (the encoder spends its budget even when the source had none). That is why the tool reports 0% saved rather than a negative number — when it happens, your file was already efficient, and the fix is fewer pixels or a lower frame rate, not a lower bitrate.

Codecs: why the same video can be half the size

The codec is the algorithm that decides how cleverly redundant information is thrown away. Newer codecs are smarter, so they need fewer bits for the same picture — but "same picture" depends on the content, and smarter codecs are slower to encode and less universally supported.

For a file you will text, upload or embed almost anywhere, H.264 MP4 is still the "it just plays" format. VP9 is the size-efficiency pick for the open web. The tool in this guide uses the browser's MediaRecorder, which is why its native output is WebM (VP8/VP9) — a trade: excellent, private, zero-install compression in exchange for a container you sometimes need to convert before a device will open it.

What a browser-based compressor actually does (and why it writes WebM)

A browser cannot run the same slow multi-pass engine as desktop software like HandBrake. Instead, tools like the ToolFlic compressor play the video, redraw each frame to a <canvas> at your chosen width, and re-record that canvas with the browser's MediaRecorder at your chosen bitrate. That is why it is fast, works on a phone, needs no install and — crucially — never uploads your file.

Two consequences worth knowing up front. First, the output is WebM, because that is the codec set MediaRecorder supports in Chrome and Edge. Second, because it re-records in real time, the encode takes about as long as the clip itself, and the quality ceiling is the browser's encoder, not a 10-pass desktop render. For "shrink a clip to send it," that is a fair trade. For "produce the smallest possible archival master," a desktop encoder still wins.

The privacy upside is the whole point: a personal or client clip stays on your machine the entire time. You can prove it — open the browser's network panel, compress a file, and watch that nothing is sent anywhere.

Recommended video bitrate by resolution

These are sensible targets for typical 30 fps footage in a modern codec; low-motion screen recordings can go well below them, and fast action or dense foliage needs a margin above. When in doubt, watch the output at full screen on your own device — you are the quality judge, not the slider.

If the resized number looks startlingly small, remember the rule from the formula: bytes scale with pixels × frames × time. A 1080p talking-head clip at 6,000 kbps for 60 seconds lands near 45 MB — plenty for email or WhatsApp — and dropping it to 720p at 3,000 kbps roughly quarters it before you even touch the quality preset.

Compress a video step by step (in the browser, no upload)

Open the Video Compressor and drop in an MP4, WebM or MOV. Everything below happens on your device.

Step 1. Note the original size and length the tool shows — that is your starting point.

Step 2. If the destination is small (phone, web thumbnail), set a max width first (e.g. 1280 for 720p). Fewer pixels is the most reliable saving.

Step 3. Pick a quality preset (Low / Medium / High) that maps to bitrate, or choose the bitrate directly. For most clips, Medium at a lower resolution beats High at full resolution for "looks fine on a phone."

Step 4. If the clip has no audio you need, tick remove audio — one fewer stream, a little smaller.

Step 5. Compress. The progress bar tracks the clip as it re-records (a 40-second clip takes roughly 40 seconds).

Step 6. Preview the result, read the new size and the "Saved" percentage (it shows 0% when a file genuinely cannot be shrunk further), then download the WebM.

Step 7. If a strict target was missed, do not just lower bitrate again — drop a resolution step or the frame rate, then re-run. You will get a better-looking file than by cranking bitrate down alone.

Shrinking for a real limit: email, messaging, web

Different destinations have different hard ceilings, so pick your settings to the destination, not to a vague "smaller."

Email. Most providers bounce around 25 MB combined. A clip that size at 30 seconds implies roughly 6,500 kbps total — but email is usually the wrong place for video; a link to a hosted file is cleaner.

Messaging. WhatsApp and similar apps cap shared video well below email (order of tens of MB for short clips). Aim low resolution, 30 fps, 1,500-2,500 kbps, and keep the clip short.

Web background / autoplay. A looping <video> hero wants tiny and silent: 720p, no audio track, 1,500-2,500 kbps, and WebM is ideal here because browsers play it natively — which happens to be exactly what this tool produces.

Social uploads. Each platform re-encodes on ingest anyway, so send it a clean, not-minimal file at their recommended resolution; over-compressing before upload just gives the platform a worse source to work from.

When browser compression is the wrong tool

Be honest about the limits, because forcing it wastes your time:

You need an MP4 that a device must accept. The browser writes WebM. If the target is an old TV, a PowerPoint embed, or an uploader that whitelists only .mp4, re-wrap or transcode with desktop software (HandBrake/ffmpeg) instead.

Very long or very large files. Real-time re-recording of a long, 4K, 60 fps file strains browser memory and patience; split long footage first, compress in parts, then join.

You want the absolute smallest archival copy. A multi-pass desktop encode with VP9/AV1 beats a single-pass browser capture on size-per-quality. The browser tool is built for "make this shareable now," not "squeeze the last byte."

Safari / Firefox caveat. MediaRecorder's WebM support is strongest in Chrome and Edge; on other browsers the same re-record path can be limited or unavailable, so run those clips through a desktop encoder.