Most video compression problems trace back to one of three things: an input the browser cannot decode, a file that exceeds the tool's hard input limits (currently 500 MiB, five minutes, and 3840 × 2160 pixels of decoded area), or source content that defeats the preset you chose. Before changing tools, change what you measure: a local re-encoder that reports actual input bytes, actual output bytes, and the resulting dimensions gives you a real comparison instead of a marketing label. The Video Compressor at /video/video-compressor/ does exactly this — it decodes a browser-compatible source in the current tab, draws each frame into a bounded Canvas, records that stream as WebM with the browser's MediaRecorder, and reports the signed byte change between the two Blobs. Because every step happens locally and nothing is uploaded, you can run multiple presets on the same source, compare the numbers side by side, and find the real cause of the failure without leaving the browser. That diagnostic discipline — measure, compare, then change one variable — is what turns a vague "the video looks bad" complaint into a concrete action.
The Most Common Video Compression Problems
Most failures fall into a small set of buckets, and each bucket has a characteristic signature. Naming the bucket is the first half of troubleshooting because the fix is different for each one:
- The file is rejected before encoding starts, often with no obvious reason in the interface.
- Compression runs but throws an error mid-way and produces no download.
- The download appears, but its size is similar to or larger than the source.
- The download plays fine in the browser but not in the destination application.
- The download plays, but only as a silent video, or with stuttering or out-of-sync audio.
- The picture looks blocky, soft, or otherwise degraded compared with the source.
The fastest way to pick the right bucket is to map your symptom to a tool behaviour. The table below pairs each visible symptom with the most likely root cause and the first check that usually confirms or rules it out.
| Symptom | Most likely root cause | First check |
|---|---|---|
| File rejected before encoding | Extension looks right but the codec is not installed in the browser | Drag the source into a new tab; if it does not play, the codec is not decodable here |
| Error appears mid-compression with no download | Source exceeded a hard limit — size, duration, per-side pixels, or decoded area | Re-check the 500 MiB, 5 minute, 4096 px per side, and 3840 × 2160 decoded area caps |
| Output is similar size or larger than the source | Noisy, high-motion, or already-efficient content on a preset that does not fit it | Read the percentage change reported by the tool, then try a different preset |
| Downloaded file plays without sound | Browser did not expose a capturable audio track through HTMLMediaElement captureStream | Confirm the source has audio in a real player, then try a different browser |
| Downloaded file will not open in another program | Recipient expects MP4 or a specific H.264 profile; the recorder produced VP9 or VP8 WebM | Convert with FFmpeg for a deterministic cross-platform container and codec |
| Picture looks blocky or soft | Preset dropped width too far for the destination's display size | Compare output dimensions to the source and to the destination's minimum |
Run a Local Re-Encode to Isolate the Cause
When the symptom is unclear, a single controlled re-encode usually turns guesswork into data. The point is to vary one input at a time and let the tool report the actual numbers, because the numbers do not lie about what changed.
- Open Video Compressor in the current tab.
- Choose a browser-decodable source no larger than 500 MiB, no longer than five minutes, and no more than 3840 × 2160 pixels of decoded area.
- Select the preset closest to your goal: Small for a 640-pixel max width at 24 fps, Balanced for 1280 pixels at 30 fps, or Quality for 1920 pixels at 30 fps.
- Start the compression and keep the tab open while the source plays in real time. Encoding runs at playback speed because MediaRecorder observes the Canvas stream, so a two-minute source takes about two minutes rather than finishing instantly.
- When the source ends, read the output dimensions, input bytes, output bytes, and the measured percentage change. The percentage is calculated only from the two actual Blob sizes.
- Download the WebM and play the full file in a real media player before deleting the original.
- If the result does not fit your destination, change exactly one variable — usually the preset — and run the source again. Choosing a new file, switching presets, cancelling, or leaving the page invalidates the active job and releases the temporary Object URLs.
That sequence gives you a clean before-and-after on a single known source. If the second run changes the symptom, you have isolated the cause; if it does not, the cause sits in the destination, the codec, or the source itself rather than in the preset choice.
Check the Input Limits First
A surprising share of "the compressor is broken" reports turn out to be "the compressor refused an unsupported input." Files may carry the extensions MP4, WebM, MOV, M4V, or Ogg, but successful decoding still depends on the codecs installed in the current browser. A valid extension cannot make an unsupported codec decodable, so the very first check is to drag the source into a fresh tab and confirm it plays. If it does not, the compressor is reporting a real constraint, not a glitch.
The four hard limits to verify before pressing start are 500 MiB total file size, five minutes of decoded duration, 4096 pixels on either side, and 3840 × 2160 pixels of total decoded area. These exist to bound memory, Canvas allocation, and real-time work, and an invalid file, unsupported decoder, over-limit duration, over-limit frame, missing Canvas stream, or unavailable WebM recorder will all surface as an error rather than as a silently truncated output. Nothing is silently cropped, truncated, or downgraded to fit.
Compare Presets Against What You Actually Need
The three presets are not labelled "good," "better," "best" because no single preset is universally right. Each one is a transparent product choice: a width cap, a frame-rate target, and a bounded bits-per-pixel heuristic that is clamped between 180 kbps and 8 Mbps. All three preserve the source aspect ratio, never enlarge the source, and round output dimensions down to even pixel values for broader codec compatibility.
| Preset | Max output width | Frame rate target | Typical use |
|---|---|---|---|
| Small | 640 px | 24 fps | You need the smallest decodable WebM and the destination accepts SD |
| Balanced | 1280 px | 30 fps | You want a generic 720p-class deliverable that holds most phone footage |
| Quality | 1920 px | 30 fps | The source is 1080p or better and the destination supports HD |
A worked example makes the trade-off concrete. A 1920 × 1080 source run through Small takes the smaller of 640 and 1920 as the new width, which is 640. Height follows the source ratio: 640 × 1080 ÷ 1920 = 360 pixels, already even, so the output dimensions become 640 × 360. That is a real reduction in pixels and the right answer when the destination only needs SD, but it is the wrong answer when the recipient will watch on a 1080p monitor.
When the Output Is Larger Than the Source
A larger output is not a bug. Compression depends on motion, noise, source codec, browser encoder, and preset, and the tool does not promise that every result is smaller. A low-motion animation may shrink dramatically, while noisy footage, film grain, camera shake, rapidly changing detail, or an already efficient source codec can produce a similar or larger file. The percentage shown is calculated only from the two actual Blob sizes.
The right response is to change exactly one variable. Try a different preset — usually moving from Quality down to Balanced or from Balanced down to Small — and rerun the same source. If the result still does not suit your needs, the bottleneck is no longer the preset; the bottleneck is the content, and a different tool with two-pass rate control will not magically defeat content that is already efficient. Reaching for a heavier encoder usually means accepting a longer encode time for the same output bytes, which is rarely a good trade.
When the Output Will Not Play or Has No Sound
WebM is the only output container, because browser MediaRecorder support for generated MP4 remains inconsistent across engines. The recorder tries VP9, then VP8, then generic WebM according to the current browser's reported support, so two browsers can produce different bytes for the same preset and source. That difference is rarely the cause of a "won't play" report; the cause is usually the destination. MP4-with-H.264-only pipelines, legacy slide decks, and hardware players that pre-date WebM will all reject a VP9 file no matter how cleanly it was encoded.
Audio is captured only when the browser exposes a capturable track through HTMLCanvasElement captureStream for the underlying HTMLMediaElement. Some browser and codec combinations do not surface an audio track even when one exists, and the tool deliberately does not normalise, remix, mute, or repair audio. The source plays audibly during real-time processing when it contains audio; use device volume if needed, but do not assume that muting the tab is the same as muting the captured track. Always verify both picture and sound in the downloaded file before deleting the original.
When to Step Outside the Browser
A local re-encode solves a specific class of problem: shrinking a single browser-decodable source to a preset-shaped WebM while reporting honest numbers. It does not normalise volume, mix tracks, remove metadata according to a certified standard, repair corrupt media, or preserve subtitles, chapters, attachments, rotation tags, colour metadata, HDR signalling, or every container feature. None of those omissions is a fault; they are the trade that keeps the tool focused on a single job and keeps every byte on your device.
For archival masters, professional delivery specifications, exact codec profiles, two-pass rate control, fixed keyframe intervals, subtitle preservation, or deterministic cross-platform output, the right answer is a maintained desktop encoder such as FFmpeg with a reviewed command. The result-checking guide walks through the verification steps that decide whether a browser-based run is enough or whether the source needs a heavier tool. Run the compressor first to confirm that the source itself is the issue, then escalate to a desktop encoder only when the compressor's honest output still does not meet the destination.
All source bytes, decoded frames, and output bytes stay in the current tab. Lizely receives no video, thumbnail, duration, file name, codec, or result. Keep the original until you have played the complete output and confirmed that size, duration, picture, sound, and compatibility meet the destination's requirements — that final playback test is the one step no troubleshooting guide can replace.
For a deeper look, see How to Troubleshoot Problems When You Use Video Crop.