How to trim a video to fit a size limit

Every compression tool asks you to choose a quality, a resolution or a target size. None of them asks how long the video needs to be. So people arrive at a hard limit treating the clip’s length as a fact about the world and its bitrate as the only thing they are allowed to touch, and then they push the bitrate somewhere it cannot survive.

Half the time the length is the thing that should move.

Ten megabytes is 83,886 kilobits

That is the entire allowance, and it is worth writing out in those units because kilobits per second is what an encoder actually consumes. Ten mebibytes is 10,485,760 bytes, which is 83,886,080 bits, or 83,886 kilobits. Every second of runtime divides into that number.

A 30-second clip gets 2,796 kbps of everything. A 60-second clip gets 1,398. The relationship is not a rough guide or a rule of thumb, it is division, and it is the whole of the subject. If you want to understand why a bitrate number behaves the way it does, the bitrate explainer covers the rest of it.

Subtract an audio track and a few percent of container overhead, and here is what a 10 MB ceiling leaves for the picture at various lengths. These are the numbers this site’s own solver aims for:

Read that column downward and the point makes itself. Between a two-minute clip and a one-minute clip there is not a settings change that closes the gap. There is only less video.

Cutting the length in half doubles everything

Because the arithmetic is a straight division, halving the duration exactly doubles the bits available per second. Nothing else you can do to a video has that property. Dropping from 1080p to 720p removes 56% of the pixels, which is a real gain but a bounded one, and it costs you resolution you might want. Moving from H.264 to H.265 buys somewhere between 20% and 50% depending on the footage, and about a third is the honest expectation, and costs you compatibility and encode time.

Trimming thirty seconds off the front of a ninety-second clip costs you thirty seconds you did not want, and it gives the remaining minute 50% more bitrate than it had. Nothing degrades. No frame that survives the cut is touched at all.

This is the only genuinely lossless way to make a video file smaller. Everything else is a trade.

Where the wall actually is

Below roughly 150 kbps, H.264 stops being able to hold a coherent picture together at any resolution. You get blocking, smearing and frames that visibly rebuild themselves after every cut. That is not a quality preference, it is the point where the codec runs out of room to describe a moving image.

Take 150 kbps as a floor, keep a 64 kbps audio track, and each common ceiling has a maximum runtime past which no amount of compression helps:

Stripping the audio buys you roughly 40% more runtime, which is why a silent screen recording can go further than these rows suggest. But if your clip is past the number in that table and it needs sound, the answer is not a better encoder. There are pages for each of these ceilings — 8 MB, 10 MB and the rest are listed on the size-target hub — and each of them will tell you the same thing when the clip is too long, which is that it is too long.

Where to make the cut

Most clips have a shorter version that is also a better version.

The dead time is almost always at the front. Recording software starts when you press the button, not when the interesting thing happens, so the first ten to forty seconds tend to be setup: the menu, the walk to the objective, the “can you hear me”, the three seconds of a black frame while the capture buffer fills. None of that is the reason you are sending the file.

There is usually dead time at the end too, and it is worse than the front because people notice a slow start and forgive it, then sit through eight seconds of nothing while they wait to find out whether the video is over.

If the clip has two separate interesting moments with two minutes of nothing between them, cut two clips. Two 20-second files at 10 MB each carry a far better picture than one 160-second file at 10 MB, and the person watching would rather have them.

Trimming without re-encoding

If you have FFmpeg, a cut with stream copy is the cheapest operation in video. Nothing is decoded and nothing is re-compressed, so a two-hour source cuts in about the time it takes to read the relevant bytes off disk:

ffmpeg -ss 00:00:38 -i input.mp4 -t 27 -c copy clip.mp4

-ss before -i seeks first and then opens the file, which is the fast form. -t 27 takes 27 seconds from that point. -c copy is what makes it lossless.

The catch is that a stream copy can only cut at a keyframe. Encoders place keyframes every few seconds, so your cut will land at the nearest one rather than exactly where you asked, and you may get up to a second or two of extra footage at the start. For most clips that is invisible and irrelevant. When it is not, re-encode and take the frame-exact cut:

ffmpeg -ss 00:00:38 -i input.mp4 -t 27 -c:v libx264 -crf 20 -preset medium -c:a aac -b:a 128k clip.mp4

That one decodes and re-compresses, so it is slower and it does cost a little quality, but the start point is where you put it.

Doing both in one pass

The compressor on this site takes a start and an end point, so the cut and the encode happen in the same run rather than in two tools. Drop a file in, drag the trim handles to the part that matters, and the length the tool uses for its arithmetic is the trimmed length, not the source length — which is the whole point. A ceiling that was impossible across the full recording usually becomes comfortable across the forty seconds you actually wanted.

That matters because target-size mode solves the video bitrate from your ceiling and the clip duration, encodes, measures the finished file and re-encodes at a corrected rate if it overshot. Handing it a 40-second range instead of a 100-second one changes the answer more than any other control on the page.

There is still a good case for trimming in a real editor first: if you need to cut something out of the middle, or join two separate moments, a start and an end point cannot express that. On an iPhone or an Android phone the built-in Photos editor handles a simple cut with two handles and no re-encode. On a Mac, QuickTime Player has Trim under the Edit menu. On Windows, the Photos app and Clipchamp both do it. Any of them produces a shorter file that is otherwise identical to the source, which is exactly what you want to feed a compressor.

If you would rather see the numbers before committing to a cut, the size calculator will tell you what a given length and ceiling leave you, and you can work backwards from a bitrate you know you want to the duration that affords it.

The version nobody wants to hear

There is a category of request that has no technical answer: a 45-minute recording that has to fit in 8 MB. People ask this, and the honest response is that 8 MB spread over 45 minutes is about 25 kbps for picture and sound together, which is well under half of what a plain mono speech track needs on its own, before a single frame of picture.

For anything in that shape the options are to link the file rather than attach it, to pay for whatever raises the ceiling, or to decide which four minutes of the 45 are the ones that matter. The Discord post covers the first two in the context where they come up most; the Discord page itself opens the tool with a sensible ceiling already set. But the third option is the one that usually produces something anybody watches.

Related reading

• What is video bitrate? — the quantity duration is dividing into.
• The Discord file size limit — the same problem where most people first meet it.
• Video size calculator — length, ceiling and bitrate, solved in either direction.