Compress Video for Email: Get Under the 25 MB Cap
By Mark Fulton · 2026-08-13 · 13 min read
Aim for about 18 MB of actual file if you know the recipient is on Gmail, Outlook.com or Yahoo; about 14 MB if they might be on iCloud; and about 7 MB if you have no idea where the message is landing. The stated caps are higher than that — mostly 25 MB — but mail servers measure your message after it has been encoded for transport, and encoding makes an attachment roughly a third larger than the file on your disk. Budget for the encoded size, not the file size, and the message goes through.
The other half of the honest answer is that the attachment is often the wrong container entirely. There are two limits in play on every email you send: yours, which you can look up, and the recipient's, which you cannot see. When the clip is long enough that fitting it means destroying it, a link is not a cop-out. It is the correct answer. This post gives you the numbers to tell those cases apart, and then compresses the file without sending it anywhere.
What size can you actually attach?
Every figure below was read off the provider's own help page on 13 August 2026. Providers change these, so the date matters more than the number.
| Provider | Stated limit | The provider's own page |
|---|---|---|
| Gmail, personal account | 25 MB per message; a larger attachment is removed and inserted as a Google Drive link instead | Send attachments with your Gmail message |
| Google Workspace, sending | 25 MB (50 MB on Enterprise Plus), measured before encoding | Gmail sending limits in Google Workspace |
| Google Workspace, receiving | 50 MB (Enterprise Standard) or 70 MB (Enterprise Plus), measured after encoding | Gmail receiving limits in Google Workspace |
| Outlook.com | 25 MB for file attachments; 2 GB for a OneDrive file shared as a link | Sending limits in Outlook.com |
| Outlook desktop | 20 MB for "internet email accounts such as Outlook.com or Gmail"; 10 MB default for Exchange business accounts | Reduce attachment size to send large files with Outlook |
| iCloud Mail | 20 MB for incoming and outgoing messages, up to 5 GB with Mail Drop turned on | Mailbox size and message sending limits in iCloud |
| Yahoo Mail | 25 MB for the sum of all attached files, incoming and outgoing | Message size limits in Yahoo Mail |
Three things that table tells you which no tool page will:
Microsoft's own documentation disagrees with itself. The Outlook.com sending-limits page says 25 MB. The Outlook desktop page says 20 MB for the same kind of account, and 10 MB by default for Exchange. Both are live Microsoft pages today. If your recipient is at a company, assume the Exchange number until proven otherwise — an administrator can set it to anything, and plenty set it low.
Two of these providers state a receiving limit, not just a sending one. iCloud caps incoming messages at 20 MB. Yahoo applies its 25 MB to incoming mail as well. So the size that matters is not the one your provider allows you to send. It is the smaller of your sending limit and their receiving limit, and you usually cannot see the second one.
Gmail's automatic Drive swap is a feature, not a failure. Google's help page says a too-large attachment is removed and added as a Drive link. That is convenient, and it is also a decision made on your behalf about where the file lives and who can reach it. Worth knowing before it happens rather than after.
Why does a 24 MB file bounce off a 25 MB limit?
Because the 24 MB never travels as 24 MB.
Email was designed to carry text. A video file is binary, and the transport path historically could not be trusted with arbitrary bytes, so attachments are re-expressed in a 64-character alphabet that is safe to send as text. That is base64, and the arithmetic is unavoidable: every 3 bytes of your file become 4 characters in the message body.
4 ÷ 3 = 1.333 → a 33% increase before anything else
+ a line break every 76 characters
+ MIME part headers and boundaries
Google's admin documentation puts the real-world figure at about 37% — its receiving-limits page states that the limits are measured after encoding, "which adds about a 37% increase." So:
- A 24 MB video is roughly 24 × 1.37 ≈ 32.9 MB on the wire.
- To land under a 25 MB ceiling measured after encoding, the file itself has to be about 25 ÷ 1.37 ≈ 18.2 MB.
- Under 20 MB, iCloud's number: about 20 ÷ 1.37 ≈ 14.6 MB.
- Under 10 MB, the Exchange default: about 10 ÷ 1.37 ≈ 7.3 MB.
That is where the 18 / 14 / 7 targets at the top come from. They are division, not a benchmark.
Now the part that produces the confusing failure. Google's sending-limits page says its values are "the limits on the total size of the message content and attachments before encoding." Its receiving-limits page says the receiving values are measured after encoding. Those are two different rulers applied to the same message. Gmail will accept a 24 MB attachment, encode it to roughly 33 MB, hand it to the recipient's server — and if that server counts the encoded size against a 25 MB ceiling, it refuses it. Your outbox says sent. The bounce arrives minutes later, from a machine you have never heard of, quoting a number that does not match anything you were told.
Budget for the encoded size and the problem disappears.
How do you compress to a specific attachment target?
Start by deciding whether to compress at all. This is the decision every page ranking for this query skips, and it takes about ten seconds.
Step 1 — cut the dead air first. Trimming is free compression: it removes bits without touching any of the bits you keep. A 25-second moment inside a four-minute screen recording does not need a compressor, it needs a trim. Do this before anything else, because it changes every number that follows.
Step 2 — pick the target from the recipient, not from your own provider.
- Recipient on Gmail, Outlook.com or Yahoo, and you know it → 18 MB
- Recipient might be on iCloud, or you are replying to an
@icloud.comaddress → 14 MB - Recipient unknown, at a company, or behind a corporate mail gateway → 7 MB
Step 3 — check the target can actually carry the clip. File size is bitrate multiplied by duration; the full derivation lives in video compression, by the numbers, and the Discord version of this problem walks the budget arithmetic through two worked examples. The one line you need:
(target MB × 8) ÷ duration in seconds = total Mbps available
Run that and read the verdict off the table:
| Clip length | Gmail / Outlook / Yahoo — 18 MB | iCloud — 14 MB | Unknown or corporate — 7 MB |
|---|---|---|---|
| Up to 30 s | 4.8 Mbps → 1080p, attach it | 3.7 Mbps → 1080p, attach it | 1.9 Mbps → 720p, attach it |
| 30 s – 1 min | 2.4 Mbps → 1080p if static, 720p to be safe | 1.9 Mbps → 720p | 0.9 Mbps → 480p |
| 1 – 2 min | 1.2 Mbps → 720p at best, 480p to be safe | 0.9 Mbps → 480p | 0.5 Mbps → 480p, or trim first |
| 2 – 5 min | 0.5 Mbps → 480p, or trim to the moment | 0.4 Mbps → trim to the moment | Send a link |
| Over 5 min | Trim to the moment, or send a link | Send a link | Send a link |
Every cell is that one division, minus roughly 128 kbps for an audio track. The resolution call comes from what those bitrates can carry: 1080p wants something in the 3–5 Mbps region to look right, 720p around 1.5–3 Mbps, and below about 0.5 Mbps you are into 480p whether you like it or not. Push 1080p into 0.5 Mbps and you get a blocky smear that is somehow also still too big.
Step 4 — compress, and know why the first attempt might miss. Quality-based encoding (CRF) targets a look, not a size, and spends whatever bits that look demands. It is why a "small" preset gives 4 MB from one clip and 19 MB from the next. Hitting a stated ceiling needs an explicit bitrate solved from the duration — exactly the division above, run backwards.
VidClip's compressor does the encode with ffmpeg.wasm, the real FFmpeg compiled to WebAssembly, running inside your browser tab. The file is read into page memory and encoded on your own CPU. There is no upload bar because there is nothing to upload; the server only ever sent you the page. For a video that is a client call, a medical scan, a bug report from a production system or somebody's kid, that matters more than the eight megabytes it saves.
Free exports cap input files at 200 MB and carry a small mark in the corner of video exports. Pro removes both and replaces step 4's guesswork with a number: type "14 MB", and it solves for the video bitrate directly — the byte budget, minus 3% for MP4 container overhead, minus the audio track, divided by duration. One pass, one file, under the line. If the target is so tight that the video bitrate would collapse, it says so instead of handing you a smear.
When is a link the better answer than an attachment?
Often. And the providers agree — every one of them has built the escape hatch into the compose window. Gmail swaps oversized attachments for a Drive link automatically. Outlook.com raises the ceiling to 2 GB for a OneDrive file shared as a link. Apple's Mail Drop takes iCloud from 20 MB to 5 GB.
The Microsoft Learn thread that ranks for this query gives that advice for a 317 MB file, and it is completely right for a 317 MB file. It is wrong for a 40 MB one, because the tradeoffs run both ways:
Attach it when:
- The clip is short enough to fit a sane target without visible damage — the table above tells you.
- The recipient needs it without signing in to anything. Not everyone can open a Drive link from a locked-down work laptop.
- It belongs in the thread as a record. Attachments live in the mailbox; links live at the pleasure of whoever owns the storage.
- The content is sensitive and you would rather not park a copy on a third party's disk with a URL attached to it.
Link it when:
- The arithmetic says the target cannot carry the clip. Below roughly 0.3 Mbps there is no resolution that survives; you are choosing between a bad video and a good link.
- The full quality is the point — a colour grade, a client deliverable, a master file.
- The recipient is going to want the original anyway, in which case compressing it once for the email and again for the handover is wasted work.
Do neither when the value is not the video. If the point is what was said, pull the audio out — a five-minute speech track at 128 kbps is under 5 MB and needs no compression discussion at all. If the point is one moment on screen, export the frame and paste it inline, where it will actually get looked at.
How do you keep a screen recording legible while shrinking it?
Screen recordings are the most common video that is too large for email — a bug report, a walkthrough, a "here is what I mean" for a client — and they break the usual advice, because the failure mode is not blockiness. It is text you can no longer read.
Crop before you scale. Pixel count is quadratic, so cropping a 1440p desktop down to the application window can remove more than half the pixels while the part you care about stays at native size and stays sharp. Crop it first; it is the only size reduction on this list that costs nothing at all in legibility.
Hold the resolution, spend the savings on quality instead. Downscaling is the standard first move and it is the wrong one here. Small text is the first thing to turn to mush when you resize, and small text is the thing the recipient was meant to read. Accept a higher CRF at native size before you accept a lower resolution.
Drop the frame rate hard. A static screen at 30 fps is the same frame thirty times a second, and the encoder handles that almost for free — but a recording that spends its time scrolling is the expensive case, because every pixel moves at once. 15 fps is genuinely fine for a mostly-still walkthrough. If you can avoid scrolling while recording, do; a cut is cheaper than a scroll.
Mute it if the narration is not carrying information. An audio track at 128 kbps costs about 0.9 MB per minute, which is a meaningful slice of a 7 MB budget. Strip it when the video already shows the thing.
Check the output at 100%, not in the preview thumbnail. The whole point is whether the error message is readable. Open the compressed file at full size and read it before you attach it.
FAQ
What is Gmail's attachment limit?
25 MB per message for a personal Gmail account, per Google's own help page, checked 13 August 2026. Attachments above that are not rejected — Google says Gmail removes the attachment and adds it as a Google Drive link instead. Two caveats. The 25 MB applies to the whole message, so several files attached together count against it collectively, not individually. And Google's admin documentation says sending limits are measured before encoding while receiving limits are measured after it, so a 24 MB attachment can leave Gmail and still be refused at the other end. Treat 18 MB as the practical ceiling for a file you want to arrive.
Does zipping a video make it smaller?
No, and this is the single most useful paragraph on the whole first page of results for this query — buried in a Microsoft Learn forum thread. An MP4 is already compressed, aggressively and lossily, by a codec designed specifically for moving pictures. ZIP is a general-purpose lossless compressor looking for repeated byte patterns, and a well-encoded video has almost none left to find. You will typically get a few percent at best, sometimes nothing, occasionally a file that is fractionally larger than the original because of the archive overhead. Worse, zipping adds a step for the recipient and gets the attachment blocked outright by some corporate mail filters. Re-encode the video instead; that is the only thing that moves the number.
Why did my email bounce after it sent?
Because your sending limit and the recipient's receiving limit are two different numbers, measured two different ways. Your provider checked the message against its own ceiling, accepted it, and handed it off. The recipient's server then applied its own — often smaller, often set by an administrator, and often counted after base64 encoding has made the message about 37% larger than the file you attached. That is why a 24 MB video, which encodes to roughly 33 MB on the wire, can clear a 25 MB sending limit and fail a 25 MB receiving limit. The bounce comes back from their mail server, not yours, which is why it arrives late and reads like it is about someone else's problem. Re-send at a smaller target, or send a link.
Can I email a video without cloud storage?
Yes — that is what an attachment is, and for a clip that fits the targets above it is the better option. Compress the file locally, attach it, send it. The only thing to be careful about is the route you take to get it small: most online compressors are themselves cloud storage, briefly. You upload the video to a company's server, it sits in a queue, it gets processed, and the output waits for you to download it. That is one more copy of your file on one more company's disk, created for the sole purpose of avoiding a copy on a company's disk. Compressing in the browser skips that entirely — the page runs the encoder on your machine, the file never leaves it, and what you attach is a file that has only ever existed on your own hardware. The one exception on this site is the Pro transcript tool, which has to send audio to a speech model to do its job.
Got a clip your mail client refuses? Drop it in the compressor and pick a target — it runs in your browser, nothing is uploaded, and there is no queue. Pro hits an exact MB figure in one pass instead of you guessing at presets.