Share zip files without splitting or signups
Project deliverables, source archives, photo sets · Updated May 2026
Drop the zip, paste the link. We don't inspect, repackage, or split your archive. The recipient downloads it as-is.
- 5 GB per zip, multipart upload from the browser
- No splitting, no "part 1 of 4" mess
- Original archive integrity (we don't open or scan)
- Free, no signup, 7-day expiry
Zip archives are how people batch many files into one shippable unit. The container is doing real work: preserving folder structure, keeping file order, and handing the recipient a single thing to download instead of forty. Most transfer services treat that container as a problem to solve by repackaging, splitting, or scanning. We treat it as the point.
The casesWhy people send zips in the first place
A developer ships a project archive: source tree plus README, maybe a build artefact and an env example, all rooted at the repo name. A designer hands over a finished site: PSDs with linked assets, fonts in a subfolder, a brand guidelines PDF at the top level. A wedding photographer batches 200 culled JPEGs from a Saturday into one folder named with the couple's surname. An academic shares a dataset with a codebook and licence file alongside the CSV. An HR team bundles the onboarding pack: contract, handbook, IT setup notes, benefits PDF.
Every one of those cases has the same two requirements. Folder structure has to survive the trip, because the relative paths are part of the deliverable. And the recipient has to see one file, not forty, because the entire reason for zipping in the first place was to avoid the forty-attachment email. Anything that flattens the structure or splits the container is undoing the work the sender already did.
The constraintsWhat email and chat do badly with zips
Gmail's attachment policy lists out the executable extensions it blocks (.exe, .bat, .ps1, .vbs, .msi, .jar, .js, and several dozen more) and explicitly notes those rules apply inside compressed archives like .zip and .tgz. Send a colleague a zip with a build artefact called build.exe inside and Gmail bounces the message. Outlook applies similar filtering and additionally strips suspicious extensions from attachments before delivery, depending on the tenant's policy.
Slack and Discord don't scan inside zips, but they don't auto-preview them either: a zip uploads as a flat attachment with a generic icon, and the recipient has to download to see what's inside. WeTransfer's free plan caps transfers at 3 GB, which a project archive with source plus assets can blow through faster than people expect. Once you're past 3 GB on the free tier you're into Pro territory, with an account, a card on file, and a monthly bill to match.
The flowHow to send a zip through sto.care
Drag the .zip onto the upload zone on the homepage. Type the recipient's email so we know where to send the link. The browser uploads directly to S3 in eu-west-1 using multipart upload, so a 5 GB archive uploads at whatever speed your connection delivers, not at a throttled free-tier rate. When the upload finishes, we mail you a confirmation with two links: one for the recipient and one to revoke the share if you change your mind.
The recipient gets a separate email with the download link. They click it, the file streams from S3 over TLS, and they save the .zip to disk. No account on either end. No app to install. The archive lands on their machine in the same container you uploaded, byte for byte, and unzips with whatever tool they already use. If the seven-day window elapses before they download, the link 404s and they ping you for a fresh one.
Hands offWhat we don't do with the zip
We don't open the archive. We don't enumerate its contents, recompress it into a different format, extract it into a folder view, or run anti-virus on the bytes inside. The browser uploads the zip directly to S3 and the recipient downloads it directly from S3. Our servers see the metadata (filename, size, uploader IP, recipient email) but never the archive's body.
Our blocked-extension list applies to the outer file. A bare .exe upload gets refused at the upload step, because services that pass executables tend to land on Gmail's blocked-domain list and become useless to everyone else. A .zip that happens to contain an .exe goes through fine: we don't look inside, so we don't know. The recipient's mail provider may still scan the zip on their end and quarantine it (Gmail will, Outlook often will). That's their network, their rules, and not something we can or want to second-guess.
Files sit in S3 with AES-256 server-side encryption (SSE-S3). That's encryption at rest with AWS-managed keys, not end-to-end. If you need true zero-knowledge for the contents, use an encrypted zip on your end before uploading: 7-Zip with AES-256, Keka, or your OS's built-in archive tool. We'll move it intact and the password stays with you.
ComparedWhere each tool stands on archive handling
FAQCommon questions about sending zips
Does sto.care open my zip to scan it?
No. We treat the archive as opaque bytes. We don't list its contents, recompress it, or run anti-virus inside it. The bytes you upload are the bytes the recipient downloads. The only thing we look at is the outer filename extension, which we use to enforce the bare-upload block list.
What happens if I include a .exe in my zip?
From our side, nothing. The archive uploads, the link works, and the recipient can pull it down. The catch is the recipient's mail provider: Gmail scans inside .zip and .tgz archives and refuses delivery if it spots a blocked extension like .exe, .bat, .ps1, .msi, .vbs, .js, or .jar (full list in Google's help). Outlook does similar filtering. If the link itself is shared over Slack or Signal those scans don't run, but if you mail the link the file still passes scrutiny because the link is plain text. The danger is when the recipient forwards the zip as an attachment.
Can I send password-protected zips?
Yes. A 7-Zip or built-in OS encrypted zip uploads the same as any other archive. The password lives entirely on your end and the recipient's, we never see it. That also defeats most recipient-side AV scans, since the contents are unreadable until decrypted. Mail providers tend to either pass encrypted archives through or block them outright as a category, depending on tenant policy.
Are there file-type restrictions on the bare upload?
Yes. We block bare uploads of .exe, .bat, .sh, .ps1, .msi, .cmd, .com, and .scr at the upload step. This is about keeping our own domain reputation clean, not about scanning your stuff. A zipped .exe goes through fine. The block list applies only to the outer file extension.
What's the maximum zip size I can send?
5 GB per upload. If your archive is bigger, split it before uploading. 7-Zip and macOS Archive Utility both support volume splitting (the .zip.001, .zip.002 pattern), and you can ship two or three sto.care links instead of one. We don't auto-split, because that would require opening your archive, which is exactly what we're not doing.
Will the recipient need a zip tool?
Most modern operating systems handle .zip natively. Windows, macOS, iOS, Android, and modern Linux desktops all open standard zip archives without extra software. 7z, RAR, and tar.gz need a tool like 7-Zip, Keka, or The Unarchiver. We don't convert formats, so whatever container you upload is what the recipient receives.
Send the archive intact. No splitting, no signup, no scan.
UPLOAD A ZIP →Need the bigger picture on free large-file transfer? Read send large files free for the full limits page. Comparing alternatives directly? See sto.care vs WeTransfer. Or, if your zip just bounced off an inbox, the file too big for email page covers what to do next.