A compressed output can grow past the source size whenever the re-encoder writes a fresh stream at a chosen bitrate, codec, and container instead of simply repacking the source bytes. A video compressor that re-encodes with VP9 inside WebM still has to honor a minimum quality floor, distribute bits across frames, and decide how many frames to keep per second, so the bytes it writes can easily exceed what an already efficient source was using. The local Video Compressor at Lizely reports the actual input bytes and output bytes plus a signed percentage change after each run, so a larger result is shown honestly in the result panel rather than being relabeled as a reduction. Content such as film grain, camera shake, rapidly changing detail, sparkles, water in motion, or a source that was already tightly encoded by a different encoder can defeat the bits-per-pixel heuristic the tool uses to pick a target bitrate, and the same preset can therefore finish smaller than the source on one clip and larger than the source on another.
Why a Re-Encode Can Grow Past the Source Size
Every modern video compressor is really a re-encoder: it decodes the source, draws it into a working buffer, and asks a codec to produce a fresh stream of bytes. The bytes that come out depend on the encoder's chosen bitrate, frame rate, resolution, codec profile, and container, not on the byte count of the file you handed it. If your source already used an efficient codec at a low bitrate and the new encoder decides to use a different default bitrate floor, the output can land above where the source was sitting even though the resolution went down.
Browser-based re-encoding is more constrained than desktop tools. The page cannot run two passes, cannot pin a keyframe distance, and cannot match an arbitrary codec profile. It asks the current browser's MediaRecorder for a VP9, then VP8, then generic WebM stream, and lets the browser pick internal parameters. The encoder still has to keep enough bits per pixel to avoid visibly destroying the picture, and that floor is what often causes an honest "this came out larger" result on a clip that looked small in the source folder.
Content Characteristics That Force a Larger Output
Compression is not a function of resolution alone. The encoder spends bits on three things: motion between frames, residual detail in each frame, and noise that the codec cannot tell apart from texture. A clip with heavy film grain, a handheld shot that shakes frame to frame, fast cuts, sparkles, water, foliage in wind, or a screen recording full of tiny cursor and text motion will keep the encoder's bitrate high even at 640 pixels wide. Conversely, a clean animated explainer with flat colors can compress to a tiny fraction of its original.
The second reason is the source codec. An MP4 exported by a phone at 4K HEVC can already be lean in bits per pixel. When a WebM encoder is asked to handle the same content, it may target a higher bits-per-pixel than the HEVC stream used, especially if the page's heuristic is tuned for typical noisy footage. The signed percentage change reported in the result panel reflects what the encoder actually wrote, which can be larger than the source even after a noticeable drop in resolution.
A third factor is the bitrate ceiling. The local tool clamps the requested video bitrate between 180 kbps and 8 Mbps, so a clip whose heuristic lands near the top of that range will produce an output at least as large as the ceiling multiplied by its duration, no matter how compact the source was.
How the Video Compressor Tells You the Real Outcome
The local Video Compressor does not advertise a guaranteed percentage drop. After the page stops recording, it reports the actual input bytes, the actual output bytes, and a signed percentage change computed only from those two values. If the output is larger, the number is positive for a growth in size; the page never relabels a growth as a reduction. The result panel also reports the output dimensions so you can confirm that the preset did not silently upscale the source.
Output dimensions are the second honest signal. The three choices cap width at 640, 1280, and 1920 pixels and never enlarge the source, so if you hand the tool a 1280×720 clip with the Balanced preset and see output dimensions of 1280×720 in the report, the encoder held the resolution constant and still produced a stream larger than the source. The bitrate floor alone can account for that on a short, efficient source. For a structured way to inspect the file before deleting the original, the guide on what to review after you use video compression walks through the same checks in more detail.
Use the Video Compressor to Verify Why the Output Grew
The fastest way to see exactly why your run came out larger is to run the same source through each preset and compare the bytes. The tool processes one clip at a time in the current tab, so the comparison stays local and the source never leaves your device.
- Pick a browser-decodable video no larger than 500 MiB, five minutes, or 3840 × 2160 pixels. If your clip is longer or larger, trim or crop it first so the page can decode it fully.
- Select the Small preset (640 pixels wide, 24 fps) and start compression. Keep the tab open while the source plays in real time; encoding runs at playback speed.
- When the result panel appears, note the input bytes, output bytes, signed percentage change, and output dimensions.
- Choose the same file again, switch to Balanced (1280 px, 30 fps), and start a second run. Note the new numbers.
- Repeat with Quality (1920 px, 30 fps). You now have three honest measurements of the same source.
- Compare the three percentages against the resolution and fps columns. A run that increased file size at a lower resolution confirms that content, not dimensions, was driving the bitrate.
- Download the WebM from each run, play the full file end to end, and only delete the source after you have confirmed picture, sound, duration, and size meet your destination's requirements.
If all three runs come out larger than the source, the clip is a poor candidate for generic re-encoding and benefits from trimming, cropping, or a desktop tool with two-pass control. If the Small run came out smaller but Balanced grew, the heuristic landed near the bitrate ceiling for the noisier, larger frame; choosing Small is the right fix for that clip.
Preset Limits and Where Each Tends to Enlarge
The three presets are transparent product choices, not universal optima. Each has a hard resolution cap, a target frame rate, and the same 180 kbps to 8 Mbps bitrate range; the bits-per-pixel heuristic that picks the actual bitrate is what differs in practice.
| Preset | Max width | Target fps | Typical reason the output grows past the source |
|---|---|---|---|
| Small | 640 px | 24 | The bitrate floor near 180 kbps still exceeds the source bitrate of a short, already-efficient clip. |
| Balanced | 1280 px | 30 | The heuristic chose a bitrate near the 8 Mbps ceiling because the clip has heavy grain, shake, or rapid detail. |
| Quality | 1920 px | 30 | The source was already at 1080p and tightly encoded; the heuristic kept bitrate high because resolution did not actually drop. |
Output dimensions are rounded down to even pixel values to keep the stream broadly compatible with decoders, and the page never enlarges the source, so a 1280×720 source on the Quality preset reports 1280×720 output. The aspect ratio of the source is preserved on every preset.
When a Larger Output Means You Need a Different Workflow
A larger result is the tool telling you that re-encoding alone cannot shrink that clip below its source size. The first workflow change to try is trimming the clip to just the part you need, because duration multiplies straight into the byte count. The second is cropping away black bars or a fixed background that does not need to be encoded at full frame. The third is choosing a preset whose target resolution is well below the source so the bits-per-pixel heuristic actually has fewer pixels to spend bits on. 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 tool is a maintained desktop encoder such as FFmpeg with a reviewed command, not any browser-side re-encoder.
Related reading: Audio, Subtitles, Metadata: What Video Compression Keeps.