Trimmed Video Bigger Than the Original? Why

A trimmed video gets bigger because trimming in a browser or editor usually re-encodes the clip instead of copying it. Re-encoding sets a fresh quality target, and if the original was squeezed harder than that target, the new file grows even though it is shorter. PixelTools' Trim Video works this way: it re-encodes with H.264 at CRF 23 (a quality level, not a size limit), so a heavily compressed source can come out larger than it went in. The fix is one of three things: lower the resolution, trim without re-encoding, or run the result through a compressor. The sections below say which fits which file.

CRF is a constant-quality setting. The encoder spends whatever bits it needs to hit that quality, so output size follows the footage, not the original file size. Phone videos, screen recordings and files already shrunk by a messaging app are often stored at a much lower quality than CRF 23 would produce, so re-encoding them asks for more detail than the original kept. Audio does the same: PixelTools writes AAC at 128 kbps, which is larger than the audio bitrate many already-compressed files carry. Long, busy footage like sport or handheld video grows less, because the source already needed a high bitrate. Static footage like slides or a screen share, with a very low source bitrate, grows the most.

We ran the same arguments the tool uses (libx264, CRF 23, veryfast, AAC 128k) through ffmpeg on two synthetic 30 second 720p test clips and cut each to its first 20 seconds. This is a synthetic test pattern, not real footage, so treat the exact numbers as an illustration of direction. A low-bitrate source of 1.78 MB came out at 2.77 MB, about 55% bigger than the whole original despite being a third shorter. A source already at a similar quality level, 4.14 MB, came out at 3.83 MB, only 8% smaller for a third less duration. Copying the streams without re-encoding gave 0.77 MB and 1.69 MB, close to the one-third cut you would expect.

Dropping the resolution is the quickest way to shrink the output. Trim Video has a resolution selector with Original, 1080p, 720p and 480p, and it only scales down, never up, so a clip already smaller than your pick is left alone. Sources above 2,560 pixels on the long edge, such as 4K, default to 1080p because encoding 4K in the browser is slow and can run out of memory. If your source is 1080p and the trimmed file is too big for an email or upload, choosing 720p cuts the pixel count by more than half. Check the preview afterwards: text and fine detail suffer first at 480p.

If you need the clip to stay the same size per second as the original, use a tool that copies the streams (ffmpeg with -c copy, or LosslessCut). The catch is that a stream copy can only start on a keyframe, so the cut lands at the nearest keyframe before your chosen second, often a fraction of a second to a few seconds early. PixelTools deliberately trims to the exact frame instead, which is why it re-encodes. Choose by what matters more: a frame-accurate cut, or a file that does not change size or quality. There is no way to get both from one tool.

If the trimmed file is still too large for where it has to go, run it through the [Compress Video](/compress-video) tool afterwards, and trim first so you compress only the part you keep. Be aware that a second pass is another lossy re-encode, so do not repeat it more than once. When the file barely shrinks even then, the video is probably already at its practical floor, which [video won't compress smaller](/blog/video-wont-compress-smaller) explains. For a size target like a 25 MB email cap, work backward from the clip length: 25 MB over 60 seconds leaves roughly 3 Mbps for video and audio together.