How to Compress Video Files for Email Attachments and Discord

The limit is smaller than the number you were given

Mail servers do not send your file as raw bytes. An attachment is base64 encoded on the way out, and base64 needs four characters to carry three bytes, so the message on the wire ends up about a third larger than the file sitting on your disk. Gmail's well known 25 MB ceiling applies to that encoded message, not to the file you picked in the file browser. In practice a video of around 18 MB is the largest thing that reliably gets through, and the headers and message body eat a little more on top.

Other services pick their own numbers and change them. Discord's free upload limit has moved more than once. Outlook, iCloud Mail and corporate Exchange servers all set their own, and an IT department can set it lower still. Trust the number the app shows you when it rejects your file, not the one you remember from a few years ago.

There are only three dials

Every video compressor, in a browser or not, has the same three things to work with: how many pixels are in each frame, how many bits per second the encoder may spend, and how long the clip runs. The third one is usually the cheapest win and the one people forget. Trimming forty seconds of tripod fiddling off the front saves more than any amount of quality tuning, and nobody wanted to watch it anyway.

The compressor here turns the first two dials for you rather than offering a row of sliders. The long edge of the frame is capped at 720 pixels, so a 1080p clip comes back 720 pixels wide. The bit budget is worked out from what the source video track was actually spending rather than from a fixed number, which for a typical 1080p phone recording lands at roughly a fifth of the original video bitrate. The budget is also clamped so it can never come out near the source rate. That clamp exists because a fixed floor used to sit above the bitrate of an already efficient clip, so compressing it made it bigger.

The audio track sets a floor

When the fast path runs, the audio is copied across untouched. It is not decoded, not re-encoded, not resized. That keeps it sounding exactly as it did and costs no processing time, but it also means the audio is a fixed cost you cannot compress away here. On a long clip of somebody talking to camera, where the picture barely moves and the voice never stops, the audio can end up being most of what is left. If the output is still too big and the picture already looks soft, squeezing the video further will not rescue you.

Speed depends on your machine, not on your file

This runs on the browser's own video codecs through the WebCodecs API rather than on a compiled encoder shipped with the page. Where your machine gives the browser hardware video encoding, it works through a clip several times faster than the clip plays. Where it does not, software encoding can be slower than simply watching the thing.

The tool measures itself while it works. If the projection says it will be slower than real time, it abandons that route and falls back to recording the video off a canvas instead. That fallback always takes at least as long as the clip runs, because it is capturing a live stream at playback speed. A three minute video means three minutes of waiting. Keep the tab in the foreground while it does, since browsers throttle background tabs and that will stretch it out further.

Where this runs out of road

The whole file is read into memory, the demuxed frames are held in memory, and the finished MP4 is assembled in memory before it is handed to you. Peak usage runs to a few times the size of the source. A phone clip or a screen recording is comfortable. A half hour 4K file is asking a browser tab to do something it was never built for, and it will either crawl or fall over.

A few other edges are worth knowing before you start:

• The fast path needs an MP4 or MOV container. WebM and MKV files take the slow real time route instead.
• There is one preset and no quality selector, so if the result overshoots your target there is no dial to nudge.
• Closing the tab, or letting the machine sleep, abandons the job. Nothing is saved halfway.
• Audio that is not AAC cannot be copied through, which pushes the whole job onto the slower path.

When a desktop tool is the better answer

HandBrake and ffmpeg hit a target file size far more precisely than this can, because they can run two passes: one to look at the video, one to spend the bits where they are actually needed. They handle hour long files and whole folders of them, they let you choose a codec and a profile, and they are not bounded by what a browser tab is allowed to allocate. If you compress video more than occasionally, install one.

Sometimes the answer is not to compress at all. If the file is 2 GB, no amount of squeezing gets it into an email without turning it into a smear of blocks. Put it in a shared drive and send the link. Compression is for the clip that is close to the limit, not the one that is fifty times over it.

Nothing leaves your machine

The video is never uploaded. Everything above happens inside the page you already have open, which matters more than it sounds when the clip is a medical scan, a recorded deposition or a child's school play. You do not have to take that on trust: open your browser's developer tools, switch to the Network tab, and compress something. No request carries your file, because none is made.