Compress a video to 200 MB

Who actually enforces 200 MB

Two hundred megabytes turns up as a per-file limit on course and learning platforms, on managed CMS hosting, on internal file shares, and as the free-tier ceiling on a good number of upload-based converters. It is also roughly where browser-based upload widgets stop being reliable, so some vendors cap there rather than field the support tickets.

More often, though, nobody is enforcing it. Two hundred megabytes is a number people pick for themselves: the size they have decided a video on their own site should not exceed, or the size that feels reasonable to send someone. That distinction is worth holding onto, because a self-imposed budget can be revised and a platform limit cannot.

What fits in 200 MB

For anything under about five minutes the ceiling has effectively stopped mattering. The budget sits above what 1080p asks for on ordinary footage, and the source is the limiting factor rather than the encoder. The only rows still worth reading are the last two.

The bitrate column is also a download speed

There is a second way to read the middle column of that table, and on this page it is the more useful one. A video that plays while it downloads needs the viewer's connection to sustain its bitrate. If the file runs at five megabits per second, the viewer needs five megabits per second, continuously, for as long as the video lasts. Fall short and the player stops to buffer.

On a desktop with fibre that is nothing. On a phone with two bars it is not available, and the failure looks like a video that stalls every twenty seconds rather than a video that looks slightly soft. Most people forgive the second and abandon the first.

The MP4 this tool writes is fragmented, so a player can start it before the whole file has arrived rather than waiting on the download. That helps, and it does not change the arithmetic: buffering ahead only works when the connection is faster than the video on average.

The proper answer for a general web audience is not one smaller file, it is several. Streaming sites encode three or four renditions and switch between them as the connection moves around. This compressor makes one file at a time, so your honest options are to encode a second, smaller rendition yourself and offer both, or to accept that the file is aimed at people with decent connections. The web delivery guide covers the two-source approach.

The question worth asking before you start

Do you need to compress this at all? Two hundred megabytes crosses any modern network without ceremony. It fits in a chat message on most paid tiers, in a cloud folder, on a memory stick from 2006. Re-encoding costs you a generation of quality you cannot get back, and buys you a smaller number on a screen.

Compression only runs one way. If this file is the master, or the only copy, or something a client might reasonably ask for at full quality in six months, compress a copy and leave the original alone. Target mode will also refuse the job outright when the file is already under the ceiling, because re-encoding something that already fits is loss with nothing on the other side of it.

The cases where 200 MB is worth the encode: the file is going on a page where load time matters, a platform is genuinely rejecting it, or the source is in a codec so inefficient that re-encoding is a gain rather than a trade. AVCHD camcorder footage and ProRes masters both sit in that last category, and both shrink enormously without anything visible happening.

Past half an hour, split it instead

The last row of the table is where 200 MB stops being generous. Half an hour inside this ceiling is a 480p budget, and a two-hour recording at the same ceiling has no answer at all.

Before you drop the resolution, ask whether the recording should be one file. A two-hour meeting cut into six sections is more useful to whoever has to watch it than a two-hour file at any quality, because they can find the part they need, and each section gets its own 200 MB. Nobody scrubs through two hours of video looking for the bit about the invoice.

This tool does not split, so that cut happens somewhere else. It is still usually the better call than compressing a long recording until the slides are unreadable. If the recording genuinely has to stay whole, go to 480p, keep the audio allowance generous because the speech is the content, and accept a soft picture. The 100 MB page works through long recordings in more detail.

Questions about the 200 MB target

Other size targets

• Compress to 5 MB The tightest ceiling here. Past about three minutes it stops being possible at all.
• Compress to 8 MB The classic chat and forum attachment wall. Tight enough that duration decides everything.
• Compress to 10 MB The default cap on a huge number of upload forms — and 25% more room than 8 MB.
• Compress to 16 MB The WhatsApp video ceiling — and the one target where the platform re-encodes after you.
• Compress to 20 MB The default in helpdesks, CMS media libraries and upload widgets. Rarely announced.
• Compress to 25 MB The Gmail attachment limit — with the base64 overhead that makes 25 MB less than it looks.
• Compress to 50 MB Roomy enough that 1080p survives on short clips. The first target that stops hurting.
• Compress to 100 MB Generous enough for real 1080p. Also GitHub's hard per-file push limit.
• Compress to 500 MB Discord Nitro's per-file ceiling, and the point where the browser becomes the bottleneck.

Compressing for a specific platform instead? Discord, WhatsApp and email each have their own page.

Or start from the file you have. Whether 200 MB is a stretch or a formality depends on what is already inside the container: MP4 , MOV , MKV , WebM , AVI , WMV , FLV , M4V and MTS / M2TS .