ZIP File Too Big for Email? Size Limits + Fixes (2026)

Short answer: the server counts your attachment after base64 encoding, which adds about a third to the bytes it sees, so a file that looks under the limit can still bounce. Then it depends what is inside: in our test zipping repetitive text saved 99.6 percent, while a JPEG shrank by only 2.2 percent and random data grew. The fix chain is: zip the documents, re-compress images and PDFs with tools built for them, aim for 15 MB raw (20 MB on the wire, fits Outlook and leaves Gmail room), and send a cloud link when the file still will not fit. Start with the ZIP Files tool if you are ready to bundle now.

Why the outbox rejects a file that looks small enough Your file 17.8 MB on disk base64 on the wire +33% bytes: 23.7 MB counted Mailbox cap Gmail 25 MB Outlook 20 MB Over the cap? bounce, or Gmail swaps in a Drive link Safe target: keep the raw file near 15 MB 15 MB raw becomes 20 MB encoded: fits Outlook exactly, sits well under Gmail Zip what shrinks (documents), re-encode what does not (photos, PDFs), link the rest

Why does email say my file is too big when it isn't?

Because you are looking at the file on disk, and the server is looking at the message on the wire. Attachments travel as text: every binary byte is re-encoded as base64, a scheme that turns three bytes into four characters. That is a permanent, mathematical +33.3 percent before anyone's policy kicks in, and it applies to every attachment from every sender.

The clearest public evidence comes from Google's own support forum, where a sender reported a 17.8 MB attachment that Gmail counted as 24 MB and bounced as over the limit. Run the numbers: 17.8 times 1.333 is 23.7, which rounds to the 24 MB the mail server saw. The file never changed size; the envelope did. We reproduced the same overhead locally: a 309,987-byte JPEG encoded to exactly 413,316 bytes of base64, which is +33.3 percent, matching the theory to the byte.

So the first translation to make is between the two numbers: what your file says and what the server counts. The server's number is always the larger one, and every limit you read about applies to it.

What are the actual attachment limits?

The big providers publish their numbers, and they are smaller than people assume once encoding is included:

ServiceStated limitWhat it countsRaw file that fits
Gmail25 MB per messageMessage on the wire; over the cap, Google replaces attachments with a Drive linkAbout 18.8 MB
Outlook.com and internet accounts20 MBTotal message including the body (Microsoft's documentation)About 15 MB
Exchange at work10 MB defaultTotal message; admins often raise or lower itAbout 7.5 MB
Any recipient serverTheir rule, sometimes lowerWhatever their administrator setCheck with them

Two details that confuse people: the limit is per message, so three 8 MB photos in one email count together, and the body text counts too (usually negligible, but a long thread with the reply history attached is not). And the recipient can be stricter than the sender's provider: a corporate mailbox with a 10 MB rule will reject what Gmail happily accepted.

Does zipping my files actually make them smaller?

Sometimes spectacularly, sometimes not at all. ZIP works by finding repeated patterns; formats that are already compressed have no patterns left to find. We measured all three cases on the same machine, same day:

File we zippedRaw sizeAfter ZIPResult
Repetitive text document (215,600 bytes of prose)215,600 B935 B99.6% smaller
Random bytes, already-incompressible data204,800 B204,979 B0.1% bigger
A JPEG photo (already compressed by the camera)309,987 B303,014 B2.2% smaller
All three together730,387 B508,884 B30.3% smaller

Read the pattern: documents collapse, media does not, and incompressible data grows by a few hundred bytes of container overhead. This is why the advice "just zip it" works for a folder of contracts and fails for a folder of vacation photos. The mixed row shows the realistic case: one compressible file carries the whole bundle.

Practical rule: zip DOCX, XLSX, PPTX, TXT, CSV and code files with confidence. Zip photos and videos only when you need them as one attachment for convenience, not because you expect the bytes to shrink.

How do I get under the limit? The 3-step chain

  1. Zip the documents. Bundle every text-based file into a single archive with the ZIP Files tool: it runs in your browser, keeps the folder structure, and for document-heavy sets this step alone usually solves the problem (99.6% in our test).
  2. Re-compress the images and PDFs separately. They will not shrink inside a zip, so re-encode them instead: the Image Compressor re-encodes photos at a quality you choose, and the PDF Compressor re-saves PDFs at lower DPI. For per-image target sizes that keep photos sharp, our guide to compressing images for email has the numbers.
  3. Check against 15 MB, then link if needed. If the result sits near or above 15 MB raw, stop fighting the cap: upload to a cloud drive and send a link with sharing set so the recipient can open it. This is the only honest answer for videos, large archives and anything already compressed twice.

What size should I actually aim for?

15 MB for the raw file. That single target works everywhere because of the encoding math:

Raw file sizeWhat the server counts (+33%)Fits Gmail (25 MB)?Fits Outlook (20 MB)?
15 MB20 MBYes, with roomYes, exactly at cap
18.8 MB25 MBRight at capNo
20 MB26.7 MBNo (auto Drive link)No
24 MB32 MBNoNo

If you want margin for a long email body or a stricter recipient server, land at 12 to 14 MB. And remember the count is per message: two 10 MB photos in one email are a 20 MB message before the body even starts, which is already over Outlook's cap.

What can't zipping and compressing fix?

The honest limits, so you know when to stop trying:

  • Already-compressed media will not budge. JPEG, PNG, MP4, ZIP-in-ZIP: our test showed 2.2% and negative savings. Only re-encoding at lower quality (images) or re-rendering (PDF) moves those numbers, and that trades quality for bytes.
  • A password-protected ZIP can grow slightly. Encryption adds its own headers, and some tools recompress nothing when encrypting. Protection costs bytes; it does not save them.
  • The recipient's server may be stricter than every table here. 15 MB is a safe target, not a guarantee: university, government and corporate mailboxes frequently sit at 10 MB or below.
  • Cloud links have their own failure mode. A link with permissions set to private bounces the problem to the recipient ("request access"), and some corporate networks block drive links outright. Set sharing to "anyone with the link can view" for documents you are willing to expose, or use the recipient's own organization's sharing when the file is sensitive.
  • Videos have no good answer inside email. A minute of phone video is often 100 MB or more; compressing it to fit would make it unwatchable. Link it, every time.

What did we actually test?

We built three files on a Windows machine and measured everything with the operating system's own tools: a 215,600-byte repetitive text document, 204,800 bytes of cryptographic random data, and a 1600x1200 JPEG photo of 309,987 bytes. Each was zipped individually and together with PowerShell's Compress-Archive, and the outputs above are the literal byte counts from that run (2026-10-26).

For the encoding figure we ran the JPEG through .NET's base64 encoder: 309,987 bytes in, 413,316 bytes out, exactly +33.3 percent, which is the theoretical 4/3 ratio with no line-wrapping added. From that measured ratio the safe-target column falls out directly: 25 divided by 1.333 is 18.8, and 20 divided by 1.333 is 15.0. The 17.8 MB to 24 MB story is a real report from Google's support forum, and our measured ratio predicts it (23.7 MB) without any adjustment.

What this test does not cover: it measures sizes, not deliverability. It cannot tell you what a specific recipient server will accept, whether a security gateway will strip an attachment, or how a particular mail app displays a link. Those are policy questions on the other end, and no local measurement can see them.

Quick FAQ

Why does Gmail say my attachment is bigger than it is?

Because the server counts the message after encoding, and attachments are converted to base64 text in transit, which adds about a third to the byte count. A user in Google's own support forum reported a 17.8 MB file arriving as a 24 MB message, and 17.8 times 1.33 is 23.7, which rounds to exactly that. Your file did not grow; the envelope did.

Does zipping reduce the size of photos and videos?

Usually not. JPEG, PNG, MP4 and ZIP files are already compressed, so a second round saves almost nothing: in our test a 310 KB JPEG shrank by only 2.2 percent and 200 KB of random data actually grew slightly. Zipping shines on documents: repetitive text shrank by 99.6 percent in the same test. For photos, use an image compressor that re-encodes them instead.

What is the maximum attachment size for Gmail and Outlook?

Google states 25 MB per message for Gmail, and larger attachments are replaced with a Google Drive link automatically. Microsoft documents 20 MB for internet email accounts including Outlook.com, and a 10 MB default for Exchange accounts at work. All of these count the message on the wire, encoding included, and a recipient's own server can be stricter than any of them.

How do I send a file that is too big for email?

Work down the chain: zip the documents, re-compress the images and the PDF with tools built for them, then check the result against the safe target of about 15 MB. If it is still over the cap, upload it to a cloud drive and send a link with sharing enabled for the recipient. Videos and already-compressed archives rarely survive the first two steps, so go straight to the link.

Why did my ZIP file get bigger after zipping?

Because ZIP adds a container around the data: headers, a central directory and per-file records. When the data inside is already compressed, there is nothing to remove and the container is pure overhead. In our test 200 KB of incompressible bytes became 204,979 bytes, a growth of 179 bytes. If a zip grows, the contents were already compressed, so zip a different set of files instead.

What size should I keep my attachment under to be safe?

Aim for 15 MB for the raw file. Since base64 adds a third, 15 MB becomes 20 MB on the wire, which fits Outlook's documented cap exactly, and it leaves margin under Gmail's 25 MB limit, whose raw equivalent is about 18.8 MB. One target, both mailboxes, no bounce messages to translate.

Sending photos instead of a bundle? Our image-for-email guide covers per-picture targets, and upload errors on forms and portals are a different puzzle with different limits.

Do it now: Select your files in the ZIP Files tool, download the archive, and check its size against 15 MB: under it, attach with confidence; over it, re-compress the images or send a link. Nothing leaves your device.

Need the file under the cap?

Bundle documents into one ZIP in the browser, then check the size against the 15 MB safe target: no upload, no signup, nothing stored.

Open ZIP Files Tool