Sending zip files, and why it keeps quietly failing

Email was never built to carry your zip

The caps are lower than most people assume. Microsoft's own guidance puts internet email accounts, which includes Outlook.com, at a 20 MB limit covering the message and the attachment together, and business Exchange accounts at a 10 MB default. Personal Gmail sits at 25 MB, and when you go over it, Gmail does not bounce you. It removes the attachment and swaps in a Google Drive link on your behalf.

Which rather settles the argument. Google's own answer to an oversized attachment is to turn it into a link.

25 MB goes fast, too. Thirty photos off a modern phone will clear it before you have finished selecting them. A single screen recording of anything longer than a minute or two will clear it on its own. The zip does not save you here, it just delays the moment you find out.

Compression stopped working on the files you actually send

Zip is genuinely good at squeezing text. A fat CSV export or a folder of logs can drop by most of its size, and that is the job it was designed for.

It does almost nothing to a JPEG, an MP4, or a PDF that is mostly images, because those formats are already compressed. You get back a percent or two, and your recipient now has to unpack something before they can look at anything.

Zipping an MP4 to get under an attachment limit is like putting a suitcase inside a slightly larger suitcase.

If your folder is photos, video and image-heavy PDFs, assume compression buys you nothing and plan around that.

Security filters treat archives as a thing to be careful with

Gmail blocks a long list of file types and applies that list even when the file is sitting inside a .zip or .tgz. It also blocks password-protected archives whose contents are another archive, which is exactly the shape people reach for when they are trying to get something past a filter. Worth knowing what that rule does not say: a plain zip of a few PDFs is not blocked by Gmail for being a zip.

Corporate mail gateways are where it gets unpredictable. Plenty of them strip or quarantine archives on arrival regardless of what is inside, because unpacking an unknown archive is a risk the security team would rather not take. Nobody gets told, on either end. The file simply is not there.

So your delivery now depends on a judgement made by software you cannot see, configured by someone you will never speak to. That is a bad position to negotiate from when the thing in the zip is a proposal.

Send a link, and pick where it lives on purpose

Links do not have the size cap, do not trip archive filters, and can be updated after you send them. The part people skip is choosing the host deliberately rather than defaulting to whatever is already open.

Google Drive is the low-friction option if the recipient is outside your company. Upload, hit Share, open General access, switch it from Restricted to Anyone with the link, set the role to Viewer, copy. The catch that catches people out: if your account is a work or school one, your admin may have external sharing switched off entirely, and you will find out mid-send.

Dropbox is worth it if you want the link locked down. Hover the file, Share, Copy link, then Manage to set view or edit. Passwords and expiry dates are paid-plan features, so a Basic account can create the link but cannot put a lock on it.

WeTransfer is fine for a genuine one-off and a poor habit. The free plan gives you 10 transfers or 3 GB in total across a rolling 30-day window, which is a couple of good weeks and then a wall. Treat it as a moving van, not a channel.

If the thing you are sending really does need to stay a zip, hosting the zip and sending the link beats attaching it every time, and the same logic applies to turning any file into a URL.

The zip tells you nothing about what happened next

I spent years in growth roles at DataBees and before that doing go-to-market for a data enrichment SaaS, sending decks, proposals and reports out on a Friday and spending the weekend guessing. With a zip you are worse off than with a single attachment, because now you do not know whether they opened it, which of the six files inside they bothered with, or whether the one that mattered got read past the first page. A pile of files with nobody standing next to it is a lot to ask of someone who is doing you a favour by looking at all.

That is the problem I ended up building LiveDocument around, though I should be straight about what it does and does not cover. It does not host zips. It takes a PDF or an image, lets you record a walkthrough that sits alongside it, shares the whole thing as one link with no download, lets you drop clickable highlights that jump the video to the bit you are talking about, and shows you page-level engagement so you can see where someone actually spent their time. There is no watermarking and no NDA gating, and if your job today is moving 4 GB of raw footage, Drive or WeTransfer is the right answer and we are not.

But it is worth asking what the zip was doing in the first place. A lot of the time it exists to bundle five files because you could not decide which one mattered. If one of them is the document and the rest are supporting material, sending the document with your voice on it and the rest linked underneath lands better than a folder someone has to unpack and interpret alone. That is roughly what a decent file sharing setup should do for you, and it is the same reasoning behind sending a PDF properly.

FAQ