2026-08-05

Gmail, Outlook, and Yahoo cap video attachments at 25MB (and how to know your export will fit before you convert)

You trim a screen recording down, attach it to an email, and it bounces back — or the send button just won't go through. Three of the biggest webmail providers all draw the same line for a video attachment: 25MB. That's a strangely small number for video specifically, since a couple of minutes of footage at almost any real-world bitrate clears it easily. Here's the current, sourced limit at each provider, and how to know — before you sit through a re-encode — whether the quality preset you're about to pick will actually fit.

The limit that actually applies right now

As of mid-2026, three major webmail providers all cap attachments at the same number:

Gmail: 25MB. Gmail's own help center is direct about it: "For personal Gmail accounts, the limit is 25 MB." Go over that, and Gmail doesn't just reject the send — it automatically swaps the attachment for a Google Drive link instead, so the file still arrives, just as a link the recipient has to click through rather than something already sitting in their inbox.
Outlook.com: 25MB. Microsoft's own support article states it just as plainly: "The attachment size limit for files is 25 MB." Outlook.com offers the same kind of fallback Gmail does — sharing a file from OneDrive instead of attaching it directly, with a much higher 2GB ceiling on that path.
Yahoo Mail: 25MB. Yahoo's own help center phrases the cap slightly differently but lands on the same number: "The sum of all attached files in a single message, both for incoming and outgoing email, must not exceed 25MB in total file size." Worth noting from that wording specifically — it's a total across everything attached to one message, not a per-file allowance you could stack.

Three unrelated companies landing on the exact same 25MB figure is a coincidence worth a raised eyebrow, not a sign of some shared technical standard — but coincidence or not, it's the number that actually gates whether your video attaches or bounces at all three.

Why the number you should target is a little under 25MB, not right at it

Attachments don't travel through email as raw bytes — they get base64-encoded first, which turns every 3 bytes of the original file into 4 bytes of encoded text, a fixed, unavoidable ~33% expansion regardless of provider. That's basic encoding arithmetic, not a provider-specific quirk, and it means a file that measures exactly 25MB on your disk can land noticeably heavier by the time it's actually in transit. None of the three providers above spell out exactly where in their pipeline that expansion gets measured against the stated cap, so the practical takeaway isn't a precise number to aim for — it's to treat 25MB as a ceiling you want real headroom under, not a target to land exactly on.

How long a clip actually fits, at each NearVid quality preset

NearVid's WebM and MP4 exports each offer a High/Medium/Low quality preset, and each preset is just a target video bitrate — 2M/1M/500k for WebM, 4M/2M/800k for MP4 — plus a fixed ~128kbit/s estimate for the audio track. Multiply bitrate by duration and you get roughly how much footage of any kind fits under a 25MB cap before you've encoded a single frame:

NearVid's own bitrate presets, run through the same 25MB math: MP4 High clears roughly 48 seconds before hitting the cap, while WebM Low stretches to about 5.3 minutes. Picking a lower quality preset — or trimming first — buys back far more headroom than any per-provider trick.

What NearVid actually does here

Next to the Quality dropdown on NearVid's WebM and MP4 export screens, a small "≈" figure now shows the expected output size for whichever preset is selected — before you press Process, not after you've waited through one. It only appears once a real duration is known, either from NearVid's own ffprobe-based duration check when you load a file, or from a start/end trim range you typed in yourself, and it updates live as you change the quality preset or adjust that range. It's worth being precise about what this number is and isn't: it's (video bitrate + a fixed 128kbit/s audio estimate) × duration, computed instantly on your device without touching the encoder — not a live test re-encode, so it's a labeled approximation rather than a guarantee. The real encoder still decides the actual audio bitrate, and a target video bitrate is an average the encoder aims for, not a hard byte ceiling, so treat the "≈" figure as "aim to land comfortably under this," not "the exact file size you'll get." The same estimate isn't shown for trim, GIF, frame extraction, or audio extraction — those either aren't a bitrate-targeted re-encode (trim is a lossless stream copy) or don't expose a quality tier to estimate from.

To be specific about scope: NearVid doesn't know about Gmail's, Outlook's, or Yahoo's specific caps, and it doesn't attach anything to an email for you — it shows you a size estimate, you compare it to whatever limit applies to where you're sending it. If a clip still won't fit even at the Low preset, NearVid's trim (a lossless stream copy, not a re-encode) is the bigger lever: cutting the source down to just the seconds that matter reduces the duration side of that bitrate × duration math directly, and costs nothing extra to do before converting. And since none of this requires uploading the original file anywhere, checking whether a clip will fit doesn't itself create the kind of server-side copy the size limit was arguably trying to avoid in the first place.

The honest summary

The numbers as of mid-2026: Gmail, Outlook.com, and Yahoo Mail all cap an email attachment at 25MB, three companies landing on the same figure by coincidence rather than any shared standard — and base64 encoding's fixed ~33% overhead means the real safe target is a bit under that line, not exactly on it. NearVid's own bitrate presets, run through that same 25MB math, fit anywhere from about 48 seconds (MP4 High) to about 5.3 minutes (WebM Low) of footage. None of those minutes change because of anything NearVid does — they're set by the providers you're sending through. What changes is whether you find out your export won't fit before or after you've sat through the re-encode: the "≈" estimate next to the Quality select answers that instantly, and trimming first is still the biggest lever if even the smallest preset doesn't get you under the line.