Getting a Video Under an Upload Limit Without Guessing

Size is bitrate times duration, and almost nothing else

A video file is a stream of bits played out at a rate. Multiply that rate by how long it plays and you have the file, give or take the container's own bookkeeping, which for a normal MP4 is a fraction of a percent. This is why file size is not really a property you set. It is an outcome. The two things you can genuinely control are how many bits go by each second and how many seconds there are, and everything a compressor does is a way of pushing on the first of those.

The conversion is worth committing to memory because it is the whole method. One megabyte is eight million bits, so one megabyte is 8,000 kilobits. Multiply the limit in megabytes by 8,000, divide by the number of seconds, and the result is the total bitrate in kilobits per second that fits. A 25 MB limit on a 60-second clip allows 3,333 kbit/s. The same limit on a 10-minute clip allows 333 kbit/s. Same limit, twenty times less room, and the difference is entirely the duration.

One trap in that arithmetic is the megabyte itself. Some systems mean 1,000,000 bytes by it and some mean 1,048,576, a gap of 4.9 %, and a service rarely tells you which it uses. Computing with the decimal figure — 8,000 kilobits per megabyte — is the safe direction to be wrong in: if the service actually meant the larger megabyte, your file simply comes in under its limit with room to spare.

CRF asks for a quality, not for a size

The quality slider on this tool sets a constant rate factor. The scale runs from 0 to 51 in the encoder; the slider exposes 18 to 34, which is the part of it anybody sensible uses, and it starts at 28. A lower number means better quality and more bits. FFmpeg's own guide calls 17 or 18 visually lossless or nearly so, and describes 17 to 28 as the subjectively sane range. The crucial property is what the number means: it is an instruction about how much distortion to tolerate in each frame, not an instruction about how many bits to produce.

That is why the same CRF gives wildly different sizes on different clips. Two minutes of a static interview at CRF 23 might land at a few megabytes; two minutes of rain on water, confetti or a shaky handheld walk through a market at the same CRF can be ten times that, because holding the same visual quality across all that movement genuinely costs more bits. The encoder is doing what you asked. You asked for a look, not a weight. FFmpeg's documentation says so in as many words: in this mode you cannot tell it to hit a specific file size or stay under a specific bitrate.

There is one regularity you can lean on, and it is the reason a couple of attempts converge so fast. The CRF scale is exponential: raising it by six points roughly halves the bitrate, lowering it by six roughly doubles it. That single rule turns a blind slider into an aiming device. Over the range this tool exposes, from 18 to 34, that is a factor of about 6.3 between the largest and smallest file the same clip can produce.

Working backwards from the limit, with a real example

Take a three-minute clip you want to email. Gmail states a 25 MB attachment limit on personal accounts, so: 25 × 8,000 = 200,000 kilobits, divided by 180 seconds, is 1,111 kbit/s in total. Subtract the 128 kbit/s this tool gives the audio and 983 kbit/s remain for the picture. YouTube's published recommendation for 1080p at a standard frame rate is 8,000 kbit/s. You are being asked to do it in an eighth of that. The clip will encode, and it will look like it was recorded through a window in the rain.

So change the question. At 720p, YouTube's recommendation is 5,000 kbit/s and you have 983 — still a fifth. At 480p it is 2,500 and you have 983, which is 39 % of it: aggressive, visibly softer, but watchable for a talking head or a screen recording. That comparison is the actual decision, and it took one division to reach. If the clip has to stay at 1080p, the only remaining lever is duration: cut it to 45 seconds and the same 25 MB gives you 4,444 kbit/s in total and 4,316 for the picture — close to the 720p recommendation and a little over half of the 1080p one, which is the point at which raising the CRF stops being cruelty.

When the arithmetic says no

Run the division on a thirty-minute recording against a 25 MB limit and you get 111 kbit/s in total — less than the audio alone needs. The budget for the picture is negative. No compressor setting solves that, and no amount of patience will make one work, because the request is arithmetically impossible before the encoder is even involved. This is the most useful result the method produces, and it is worth reaching before you spend twenty minutes encoding.

The honest answers at that point are all about duration or about the destination. Trim the recording to the part that matters — the video trimmer will do that in seconds without re-encoding anything, at the cost of landing on a keyframe rather than exactly where you asked. Split it into parts. Or change the channel: WhatsApp's own help pages state a default video limit of 100 MB and 720p on a fast connection and 64 MB and 480p on a slow one, while documents sent through the same app go up to 2 GB, so sending a video as a document is a route around both the size limit and the app's own re-compression.

The flag that moves the index to the front

Every MP4 this tool produces is written with +faststart, and it is worth a paragraph because it is the difference between a file that plays and one that appears broken. An MP4 stores its media data in one box and its index — the table saying where every frame lives, called the moov atom — in another. By default the encoder writes the index last, because it cannot know the final layout until the last frame is written. A player reading such a file from a web server has to reach the end of the download before it can start.

The faststart flag makes the encoder do a second pass over the finished file and move that index to the front. FFmpeg's own documentation describes it exactly that way, and notes that it is not on by default because the extra pass takes time. YouTube asks for the same thing in its upload recommendations: the moov atom at the front of the file, which it calls Fast Start. The practical effect is that your video starts playing while it is still arriving, instead of showing a black rectangle until the last byte lands — which is what an upload preview, a chat client or a web page will do with a file that lacks it.

What the tool actually runs, and where

There is no mystery in the pipeline, so here it is in full. The compressor encodes the picture with libx264 at the preset veryfast and the CRF you chose, encodes the sound with AAC at 128 kbit/s, and writes the result as an MP4 with the faststart flag. That is the entire command. The preset is a speed-versus-efficiency dial rather than a quality dial: a slower preset would produce a slightly smaller file at the same CRF, and veryfast is the compromise that keeps a browser-based encode from taking all afternoon.

That encoder is FFmpeg compiled to WebAssembly and it runs inside the page, on your machine. The engine is about 32 MB and it is served from this site's own address rather than a third-party network, so the only thing that travels is the engine coming to you — the video never goes anywhere. The build is single-threaded, which is why it is slower than a desktop encoder that spreads the work across every core you have, and why a long clip is genuinely a long wait. Keep the tab in the foreground while it works: the job lives in the page and nothing on a server is holding your place.

Frequently asked questions

Why can I not just type the file size I want?

Because hitting a size exactly requires the encoder to see the whole clip before deciding how to spend its bits, which means encoding it twice. That is what two-pass mode does: the first pass measures where the difficult moments are, the second spends the budget accordingly. It is the correct answer when a size is a hard requirement, and it costs roughly double the time. This tool runs a single pass at a constant quality, which is the right trade for a browser-based encoder where the second pass would double a wait that is already long. The arithmetic in this article is how you get single-pass CRF to land where two-pass would.

My compressed file came out bigger than the original. How?

Because the CRF you asked for was more generous than the quality the file already had. Compression is not a ratchet — the encoder does not know or care what the input weighed, it just produces whatever a given quality level costs. A clip that was already squeezed hard, a download from a messaging app or a screen recording of mostly static content, may need more bits at CRF 23 than it currently occupies. Raise the CRF. The other common cause is an audio track that was originally smaller than 128 kbit/s, since this tool always re-encodes it at that rate.

Should I lower the resolution or raise the CRF?

Compare your budget with what the resolution wants and let the gap decide. If the budget is within a factor of two of the recommendation, raise the CRF — the picture will soften but stay sharp-edged. If the budget is a fifth of it or less, lower the resolution instead: an encoder starved that far produces blocking and smearing that are far uglier than the same footage rendered honestly at a smaller size. The rule of thumb is that a picture with too few pixels looks small, while a picture with too few bits looks broken, and viewers forgive the first much more readily.

Does the audio setting matter at all?

It matters exactly when the clip is long and the limit is small. At 128 kbit/s the sound costs about 0.96 MB per minute, so a two-minute clip spends under 2 MB on audio and nobody cares, while a twenty-minute recording spends over 19 MB on audio alone — which is why the thirty-minute row of the table is impossible at 25 MB. This tool does not expose an audio control, so when the sound is the problem the answer is to shorten the recording, or to accept that a long piece of talking wants a different container entirely and extract the audio track on its own.

The upload still failed even though my file is under the stated limit.

Three things do this regularly. The stated limit may apply to the whole message rather than to each attachment, so your other files count too. The service may measure the encoded upload rather than the file on disk, which adds roughly a third for an email attachment. And published figures go stale: Discord's own File Attachments FAQ, read on 13 August 2026, states that the free upload limit is now 20 MB, raised from 10 MB in August 2026, with Nitro Basic at 50 MB and Nitro up to 500 MB — while an older paragraph on the same page still says 10 MB. When a page contradicts itself, aim under the smaller number.