Video Won't Compress Smaller? Here's Why

A video stops getting smaller when it hits a real bitrate floor, or when the source was already compressed once. To put numbers on that, we ran a 10 second 720p test clip through the exact ffmpeg arguments the PixelTools compressor uses. The first pass cut 5,433,449 bytes down to 2,107,551, a 61 percent drop. A second pass on that output saved only 14.5 percent more, a third only 10.8 percent. On a file that was already thin, 512 kbps overall, the same default setting produced a file 65 percent larger than the original. Past the floor the fix is not a stronger compression setting, it is lower resolution, a shorter clip, or a target size mode that does the arithmetic for you.

Compressors cap how low the bitrate can go on purpose, and PixelTools' target size mode makes that cap easy to see. Its planner works backwards from your byte budget, steps audio down through 128, 96 and 64 kbps as the budget tightens, and will not plan video below 100 kbps. Asking for 0.2 MB from our 10 second clip hits that wall: the plan floors at 100 kbps video plus 64 kbps audio, and the encode landed at 220,807 bytes, about 10 percent over the request. The tool flags that case rather than quietly shipping an unwatchable file. Ask the same clip for 1 MB and the planner picks 608 kbps video plus 128 kbps audio, and the result lands at 941,134 bytes, comfortably under. The floor is physics plus a deliberate quality decision, not a conservative default you can out-argue.

Measured on one 10 second 720p clip, each pass using the compressor's default quality setting (slider 60, which maps to CRF 26, preset veryfast, AAC audio at 128 kbps). Source: 5,433,449 bytes. Pass 1: 2,107,551 bytes, 61.2 percent smaller. Pass 2: 1,801,726 bytes, 14.5 percent smaller than pass 1. Pass 3: 1,607,397 bytes, 10.8 percent smaller than pass 2. The first pass does nearly all the work, and every pass after it re-encodes data that has already been squeezed once, so it buys a shrinking fraction while adding fresh quality loss. If your file barely moves between attempts, the source content is the constraint now, and more passes trade visible picture quality for a few percent of size.

The problem reported as "it will not compress" is often the opposite: the file grew. We encoded the same 10 second clip at 400 kbps video plus 96 kbps audio, giving a 639,934 byte file at about 512 kbps overall, then ran the compressor's default quality setting over it. The output was 1,053,572 bytes, 65 percent larger, because CRF 26 asked for roughly 842 kbps of video on a source that was already down at 512. Even the most aggressive slider position (quality 10, CRF 35) came out at 716,783 bytes, still 12 percent above the original. A quality based mode targets a picture quality, not a size, so on an already thin source it will happily spend more bits than the source ever had. Use a target size mode there, or leave the file alone.

Once bitrate is maxed out, three levers still move file size. Resolution is the largest: a 1080p version of our clip compressed to 3,909,228 bytes at the default setting, and to 1,055,617 bytes with the tool's 720p cap applied, 73 percent smaller. A synthetic test pattern flatters that lever, so expect something closer to 40 to 50 percent on real camera footage, but the direction holds. Trimming is close to linear, so halving the runtime roughly halves the file. A newer codec helps if you are still on an old one. Dropping frame rate helps on screen recordings and slideshows, not on fast motion. Audio has the least headroom of all: the compressor's own planner only steps audio from 128 down to 64 kbps, worth 64 kbps against video budgets in the hundreds or thousands.

Divide the file size in bits by the duration in seconds to get the source bitrate, then compare it with what you are asking for. Our 512 kbps test file is the clean case: the default quality setting wanted about 842 kbps for the same picture, so there was nothing left to remove and the output grew instead. If the most aggressive setting changes the size by only a few percent and the picture already looks worse, that is the floor as well. One more check costs nothing: run the same file through a different tool. If it lands at roughly the same size for the same visible quality, the limit is in the content, not in the settings you picked.

If the real goal is a platform cap, Discord's free tier 20 MB limit or Gmail's 25 MB attachment ceiling for example, use a target size mode instead of guessing with a quality slider. The planner does the size and duration arithmetic for you and reserves about 8 percent of the budget for container overhead, which is why our 1 MB request came back at 941,134 bytes rather than just over the line. When the arithmetic drives video below the 100 kbps floor, no setting rescues it: our 0.2 MB request came out 10 percent over. At that point trim the clip or drop the resolution first, because both reduce the total bits needed rather than fighting the floor.

Every number above came from ffmpeg 6.1.1 on Linux, run on 2026-11-13, with the same arguments the in-browser engine passes. The source clip was built with: ffmpeg -f lavfi -i testsrc2=size=1280x720:rate=30:duration=10 -f lavfi -i sine=frequency=440:duration=10 -c:v libx264 -crf 18 -preset veryfast -pix_fmt yuv420p -c:a aac -b:a 128k source.mp4. Each compression pass then ran: -c:v libx264 -crf 26 -preset veryfast -c:a aac -b:a 128k -movflags +faststart. Two honest caveats. A synthetic test pattern is not camera footage, so read the ratios rather than the absolute byte counts, and real footage usually shows smaller gains from downscaling. And the browser build of ffmpeg can differ by a few percent from the desktop binary on identical settings.