A bad-looking compressed video is almost always the wrong preset for the source rather than a broken encoder, and the fastest fix is to re-encode the file locally with a different preset while reading the reported output dimensions and byte change against your original. Compression trades detail for size, and every preset on a browser-based compressor caps width, frame rate, and bitrate inside fixed ranges. When the result looks wrong, the cause usually narrows to one of three things: the preset was too aggressive for the source content, the browser's encoder produced different output than another browser would, or the file genuinely cannot be made smaller without visible loss. The Video Compressor addresses each case by re-running the encode locally, showing the actual output dimensions, listing the input and output bytes, and printing the measured percentage change between them. Nothing is uploaded, so you can try every preset in turn and compare the downloaded files in the same browser tab before deciding which one to keep.
Why a Compressed Result Looks Wrong
Three things account for nearly every "this looks wrong" reaction after a compression pass. The first is preset mismatch: a clip full of camera shake, grain, or rapid motion demands more bitrate than the preset allocates, so the encoder keeps macroblocks large and the picture turns soft or blocky. The second is browser encoder behaviour: the tool tries VP9, then VP8, then generic WebM according to what the browser reports, so the same preset on the same source can produce visibly different bytes in Chrome versus Firefox versus Safari. The third is source ceiling: an already-efficient codec such as a recent HEVC encode may already be near its information limit, and any re-encode adds framing overhead and a different codec, which can make the file larger or only marginally smaller.
A fourth, less obvious cause shows up after the download rather than during compression. WebM containers do not preserve subtitles, chapters, attachments, rotation tags, HDR signaling, or many color metadata fields. If your destination expects those fields and the output plays but appears "wrong" — wrong orientation, missing captions, washed-out highlights — the issue is missing metadata, not a bad encode. Audibility is a similar trap: the tool includes audio only when the browser exposes a capturable track through the media element capture method, so a silent output on a source that has audio usually means the browser could not route that track for capture, not that the encoder dropped it.
What the Video Compressor Actually Controls
Each preset is a bounded set of encoder choices, not a universal promise about how small or clean the result will be. Small caps width at 640 pixels and targets 24 frames per second. Balanced caps width at 1280 pixels and targets 30 fps. Quality caps width at 1920 pixels and targets 30 fps. Every preset preserves the source aspect ratio, never enlarges the source, and rounds the output dimensions down to even pixel values for broader codec compatibility. The tool then picks a target bitrate from a bits-per-pixel heuristic and clamps that request between 180 kbps and 8 Mbps before handing it to the recorder.
| Preset | Maximum width | Target frame rate | Bitrate range | Best suited for |
|---|---|---|---|---|
| Small | 640 px | 24 fps | 180 kbps–8 Mbps (clamped) | Previews, thumbnails, short clips where size matters most |
| Balanced | 1280 px | 30 fps | 180 kbps–8 Mbps (clamped) | General sharing, screen recordings, talks |
| Quality | 1920 px | 30 fps | 180 kbps–8 Mbps (clamped) | Sources worth keeping close to original detail |
The fact that every preset shares the same clamped bitrate range matters when a result looks wrong: switching presets changes the pixel budget more than the bitrate ceiling, so a noisy 4K source on Quality is still capped at 8 Mbps, which can be too little for that content. A full discussion of how preset choice shapes quality lives in How to Choose Quality When Compressing a Video, and the meaning of the reported percentage is covered in Video Compressor Accuracy: What It Actually Reports.
Fix a Bad Result With the Video Compressor
Use this workflow whenever the previous output looked too soft, too small, the wrong shape, or larger than the source.
- Open the Video Compressor in your browser tab and choose the original source file. The tool accepts MP4, WebM, MOV, M4V, and Ogg names, but actual decoding still depends on the codecs installed in the current browser, so a valid extension cannot rescue an unsupported codec.
- Confirm the source fits within the disclosed limits — up to 500 MiB, up to five minutes, up to 4096 pixels on either side, and no more than 3840 × 2160 of decoded area. Anything outside those limits produces an error and no download, which is itself a useful diagnostic signal.
- Pick a different preset than the one that produced the bad output. If Small looked too soft, try Balanced. If Balanced looked sharp but choppy, try Quality. If Quality looked almost identical to the source but barely shrank, try Balanced.
- Start compression and keep the tab open while the source plays in real time. Encoding observes the Canvas stream while the video plays, so a two-minute source takes about two minutes rather than completing instantly.
- Read the reported output dimensions, the input bytes, the output bytes, and the signed percentage change. The percentage is calculated only from the two Blob sizes and never claims a file shrank when it grew.
- Download the WebM, play it fully in a player outside the browser tab, and check picture, sound, duration, and compatibility with the destination before deleting the original.
What to Inspect in the Downloaded File
The percentage is a starting point, not a verdict. A large reduction on a clip full of motion can still look worse than a smaller reduction on a talking-head clip, because the bitrate heuristic responds to pixel count and frame rate rather than to motion complexity. Open the downloaded WebM in a media player and confirm four things in order: that the picture is sharp enough for the destination, that audio plays for the full duration when the source had audio, that the file opens in whatever app or platform will receive it, and that the duration is finite rather than reported as unknown. The tool inserts a Matroska duration value in timestamp-scale ticks so playback knows the length, but some players ignore that field on a non-standard container, so verify rather than trust.
If the file is larger than the source, that outcome is allowed by the design: compression depends on motion, noise, source codec, browser encoder, and preset, and the tool reports actual bytes without relabelling a larger file as a reduction. In that case the next step is to try a smaller preset or accept that the source is already efficient enough that re-encoding adds overhead rather than removing it. Treating the output as the next comparison point rather than the final answer is the core skill behind fixing a wrong-looking result.
When a Preset Is Not the Right Fix
Some "wrong" results are not preset problems at all. If the source has subtitles, chapters, attachments, rotation tags, or HDR color metadata, the WebM output will not carry them, and no preset change will bring them back. If you need a deterministic, two-pass encode with fixed keyframe intervals and exact codec profiles — for example, for an archival master or a delivery spec that names a specific H.264 profile — a browser re-encode is the wrong tool, and a maintained desktop encoder such as FFmpeg with a reviewed command is the correct one. The Video Compressor explicitly defers to that case rather than pretending to cover it.
Orientation issues are worth checking separately. The tool does not preserve rotation tags, so a portrait phone clip with a rotation flag in the source will play at landscape dimensions and look stretched. Fix the rotation in a player or in the source before re-encoding so the encode sees the correct width and height to begin with. Captions that worked in the source and disappeared in the output are a metadata loss, not a quality loss, and the right fix is to remux or reauthor the captions in the destination player or editor.
Practical Limits That Can Make a Result Look Wrong
The disclosed input limits — 500 MiB, five minutes, 4096 pixels per side, and 3840 × 2160 of decoded area — exist to bound memory, Canvas allocation, and the real-time work of the browser's media recorder. Hitting any of them produces an error and no download rather than a truncated file, which keeps silent corruption off the table. Encoding runs at the cadence of source playback because the recorder observes the Canvas stream while the source plays, so closing the tab, choosing a new file, changing presets, or navigating away cancels the active job and releases temporary Object URLs.
Two practical consequences follow. First, a long source is a long wait: a five-minute clip takes roughly five minutes, and the tab must stay focused enough to keep playback running. Second, the encoder the browser exposes decides a surprising amount of the output. The same preset and source can produce visibly different results in Chrome versus Firefox versus Safari because the recorder tries VP9, then VP8, then generic WebM according to what the browser reports. If the result looks wrong in one browser, opening the same source in another browser with the same preset is a legitimate diagnostic step. All source bytes, decoded frames, and output bytes stay in the current tab throughout, and Lizely receives no video, thumbnail, duration, file name, codec, or result, which means you can iterate through presets without sending the file anywhere.