Video compression has no universal sweet spot — every preset, bitrate, and resolution choice trades file size against visible detail, and a misread preset can shrink a quiet animation dramatically while pushing a noisy camera clip to the same size or even larger than the source. Practical video compressor tips come down to matching the preset to the destination, reading the actual byte change instead of chasing a promised target, and verifying the output plays back with sound before the original is deleted. Common mistakes start with assuming a smaller number on the slider always means a smaller file, ignoring audio and metadata that the browser-based pipeline cannot preserve, and treating real-time encoding as if it were an instant cloud job. A local re-encoding tool such as the Video Compressor handles those trade-offs honestly because it reports the real input and output bytes and never enlarges the source dimensions, so you can compare results side by side without trusting a black-box promise, and rerun with a different preset when the output doesn't suit the destination.

Common Compression Mistakes That Lead to Bigger Files
The fastest way to waste a compression run is to skip the diagnosis. These are the recurring mistakes that turn a "compress" button into a no-op or, worse, a file that grew.
- Trusting the preset name as a guarantee. Small, Balanced, and Quality describe width and frame-rate caps, not a fixed output size. A noisy camera clip at the Quality preset can still come out heavier than the source if the source was already efficiently encoded.
- Feeding an unsupported codec. A valid .mp4 extension does not guarantee the browser can decode it. When the decoder fails, the tool surfaces an error rather than producing a corrupt WebM, and that error is the signal to remux the source or pick another file.
- Closing the tab "to speed things up." Encoding runs in real time while the source plays through a Canvas stream. Closing the tab cancels the active job and releases the temporary Object URL, leaving no download behind.
- Reading the percentage in the wrong direction. A positive number is a reduction; a negative number is growth. The tool reports the signed byte change honestly, so a result that came out larger is shown as larger rather than relabelled as a saving.
- Deleting the original before verifying. Audio tracks, chapters, subtitles, rotation tags, color metadata, and HDR signalling are not preserved. The only safe deletion is after the downloaded file has played end-to-end with picture and sound.
Preset Differences at a Glance
The three presets are explicit width and frame-rate ceilings, paired with a bounded bits-per-pixel heuristic that selects the recorder bitrate inside an 180 kbps–8 Mbps clamp. Knowing which cap matches your destination keeps you from retrying the same run twice.
| Preset | Max width | Target fps | Typical use |
|---|---|---|---|
| Small | 640 px | 24 | Previews, chat attachments, low-bandwidth sharing |
| Balanced | 1280 px | 30 | Slide decks, internal reviews, standard social posts |
| Quality | 1920 px | 30 | 1080p-style playback where detail matters more than a few extra MB |
Every preset preserves the source aspect ratio, rounds output dimensions down to even pixel values for codec compatibility, and never enlarges the source. A portrait clip on a 1920-px cap stays a portrait clip; a 720p source on the Quality preset stays at 1280 wide because that is already its native width.
How to Run a Compression Without Wasting a Run
The steps below are the shortest path from file selection to a verified download. Treat each step as a checkpoint; skipping any of them is one of the recurring mistakes the article is built around.
- Pick a browser-decodable source. The file must be at most 500 MiB, five minutes long, and within 3840 × 2160 of decoded area, with no side over 4096 pixels. MP4, WebM, MOV, M4V, and Ogg names are accepted, but decoding still depends on the codecs installed in the current browser.
- Open the Video Compressor and load the file. Everything happens locally: decoding, Canvas drawing, MediaRecorder encoding, and download. No bytes leave the tab.
- Choose Small, Balanced, or Quality based on the destination. Match the cap to the largest display the file will actually play on, not to a target MB number you read somewhere.
- Start compression and keep the tab open. The source plays audibly while the recorder captures the Canvas stream at the preset cadence. A two-minute source therefore takes about two minutes; this is real-time work, not an instant cloud job.
- Read the actual numbers. When the source ends, the tool reports output dimensions, input bytes, output bytes, and the signed percentage change. Compare those against the destination's limits, not against a guess.
- Download the WebM and play it fully. Listen for audio where the source had audio, and confirm picture and duration match expectations. Only then is it safe to delete the original.
- Rerun with a different preset if the result does not suit you. Choosing a new file, switching preset, or cancelling invalidates the active job and revokes temporary Object URLs, so each rerun starts clean.
Why a "Smaller" Preset Can Produce a Larger File
Compression is content dependent, and the tool does not hide that fact. A low-motion animation or a clean screen recording re-encodes very efficiently, often producing an output that is a small fraction of the source size. Noisy footage, film grain, camera shake, rapidly changing detail, or an already efficient source can do the opposite: the new WebM container, fresh keyframes, and a fresh encoder can end up larger than what you started with.
The reported percentage is calculated only from the two actual Blob sizes, so a result that grew is still shown as growth rather than relabelled as a reduction. When that happens, the right move is usually a different preset or a different source — not a higher bitrate dial that the tool does not expose. For sources you control, the better upstream fix is often a quieter capture (less grain, less shake) rather than a harder squeeze at the end. For a closer look at how that percentage is computed and what it does and does not promise, the Video Compressor accuracy guide walks through the formula in plain English.
What the Browser Pipeline Doesn't Carry Over
Knowing what survives the trip is the difference between a clean export and a support ticket. The browser pipeline is built around a Canvas stream and a MediaRecorder, which means it draws pixels, captures audio when the browser exposes a track through HTMLMediaElement captureStream, and writes a WebM container. It does not run a full Matroska-aware remux, and it cannot reach fields that only a real container pass would touch.
| Carried over | Not carried over |
|---|---|
| Pixel frames at the preset's width, frame rate, and bitrate | Subtitles, chapters, attachments, and sidecar text tracks |
| One audio track when the browser exposes a capturable track | Multiple audio tracks, normalised volume, mixed channels |
| Finite WebM duration set via Matroska Duration in timestamp-scale ticks | Original rotation tags, color metadata, and HDR signalling |
| Aspect ratio preserved without enlargement | Source codec profile, GOP structure, and exact keyframe intervals |
For each "not carried over" row, the safeguard is the same: play the downloaded file in the player that matters most, and only retire the source once you have confirmed picture, sound, duration, and compatibility there.
When a Desktop Encoder Is the Better Choice
Local browser re-encoding is the right tool when the goal is a quick, private reduction for sharing, review, or a slide deck, and when the destination accepts WebM. It is not the right tool when the job needs a delivered spec rather than a reasonable approximation. Archival masters, broadcast delivery, exact codec profiles, two-pass rate control, fixed keyframe intervals, subtitle preservation, or cross-platform deterministic output all sit outside what the Canvas-plus-MediaRecorder pipeline can promise.
For those cases, a maintained desktop encoder gives you the controls the browser hides. The decision is rarely either / or; the more useful pattern is to use the local browser tool for fast private drafts and to switch to a desktop encoder once the deliverable has to match a written specification.
For a deeper look, see Extract Frames from Video: Tips and Common Mistakes.