Compress a video to 500 MB

What sits at 500 MB

The best-known one is Discord's full Nitro tier, which allows 500 MB per file where a free account gets a small fraction of that and Nitro Basic sits in between. Those numbers have moved more than once, so check the app before you commit an hour to an encode. The history of that limit covers how it got where it is.

Elsewhere 500 MB shows up as a per-file cap on enterprise file shares and asset portals, on some learning platforms for video assignments, and at the top of what upload-based converters will accept from a paying customer. And as with 200 MB, it is frequently self-imposed: the size somebody decided a delivered edit should not exceed.

What fits in 500 MB

There is very little to interpret in this table. Every row through ten minutes sits well above what 1080p asks for on ordinary footage, and even the half-hour row still holds 1080p. If your clip is under half an hour and the ceiling is 500 MB, picture quality is not the thing you are trading.

At this size the browser is the constraint, not the ceiling

A 500 MB target implies a source considerably larger than that, and the source is where the real limit lives. Everything happens inside this tab: the input file is written into the FFmpeg module's memory, the decoder allocates working buffers on top of it, and the output accumulates alongside both. All of it is resident at the same time.

WebAssembly addresses memory in 32 bits, which puts a hard four-gibibyte ceiling on what the module can hold regardless of how much RAM the machine has, and browsers hand out considerably less than that in practice. A multi-gigabyte source can therefore fail on a machine with 32 GB of memory for reasons that have nothing to do with the memory, and when it fails it usually fails as a crashed tab rather than as a message you can act on.

The practical version: on a desktop with a few gigabytes free this works, slowly. On a phone it will not. Keep the tab in the foreground, because a backgrounded tab gets throttled and the encode stops making progress. If the source is very large and this keeps dying, that is a genuine case for a desktop tool. The comparison page is honest about where the browser stops being the right answer, and HandBrake handles sizes this one cannot.

A 500 MB target is usually a transcode, not a compression

At a ceiling this high you are rarely squeezing an already-efficient file. You are converting something that was never intended for delivery. Three sources account for most of it: a ProRes or DNxHD master out of an editor, which barely compresses on purpose so that colour work has room to move; an AVCHD dump straight off a camcorder, which is H.264 but at a capture bitrate and usually interlaced; and a multi-hour OBS recording written at a fixed high bitrate because dropping frames mid-stream is worse than a big file.

All three carry enormous slack, and the win comes from replacing a capture codec with a delivery one rather than from starving the encoder. Expect a large reduction with nothing visible happening, which is not a sentence this site gets to write often. The relevant pages are MOV for ProRes, MTS and M2TS for camcorder footage and MKV for long recordings.

Half a gigabyte takes real time in a tab

This is the cost nobody quotes. H.264 encoding here runs through libx264 compiled to WebAssembly, multi-threaded where the browser allows it, and it is slower than the same encoder running natively. A half-hour 1080p source is a long wait, long enough that it is worth setting the job up properly rather than iterating towards it.

Target-size mode makes a bad guess expensive. It measures the finished file, and if the encode landed over your ceiling it scales the bitrate and runs the whole thing again, up to three passes. At 8 MB that loop costs you seconds. At 500 MB it costs you the encode twice.

So set the resolution deliberately before you start instead of leaving it on original and hoping. And if 500 MB is a preference rather than a hard limit, use Best compression with the quality slider, which is a single pass. A file that lands at 480 or 540 MB is perfectly fine when nothing is actually measuring it. How the tool works goes through the modes.

Questions about the 500 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 200 MB Big enough that the real question is your viewer's patience, not the platform's limit.

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

Or start from the file you have. Whether 500 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 .