Split ZIP into Smaller Parts

Split ZIP is for the moment a single archive is too big for the channel you need to send it through. You pick a maximum part size, and the tool distributes the files inside your ZIP across several smaller, self-contained ZIPs that each stay under that limit. Built-in presets cover common ceilings: 5 and 10 MB, 20 MB (Outlook), 25 MB (Gmail), 50 and 100 MB, plus a custom value for any portal or storage limit you specify.

Typical uses: emailing a large bundle in attachment-sized chunks, sharing a backup through a chat app or cloud folder with a size cap, and getting a submission past a portal that rejects oversized uploads.

The defining trait is that every output part is a normal, independent ZIP. That makes it a good choice when the recipient may not have specialized archive software and just needs to open each file with whatever their system already provides.

Drop or select one .zip file (accepted up to 500 MB). The tool reads the archive locally, then shows the part-size controls. Choose a preset or enter a custom MB value, click Split, and it walks the files in their original order, adding each to the current part until the next file would take the part over your limit: at which point it starts a new part. The size of each file is known in advance, because files are copied into the parts exactly as they were stored in your ZIP, with their dates and permissions, so the parts land under the limit rather than roughly near it. You then download each part individually or use Download all, and files are named after the original with a -part1.zip, -part2.zip suffix. You can change the size and split again.

What it supports: ZIP input, and ZIP output as multiple complete archives, each keeping every file's full folder path. Everything runs in your browser through an in-page ZIP library; nothing is uploaded, and nothing persists once the tab closes.

What it does not do is equally important. It does not create a true multi-volume split archive (.zip.001, .zip.002 or .z01) where the parts must be rejoined before extraction. Each part here stands alone. It also will not split a single file across parts: that is a property of the ZIP format, not a tool limitation.

The most common surprise is expecting multi-volume behavior. Because each part is a separate archive, the recipient cannot select all parts and extract once; they open each ZIP on its own. If you specifically need rejoinable volumes, this is the wrong tool, and you should say so when you send the parts.

A single file larger than your chosen part size cannot be made to fit by splitting. The tool places such a file in a part of its own and marks that part as over the limit. If you need that file under the limit too, shrink the file itself first (for example with an image or PDF compressor) and rebuild the ZIP.

Finally, mind the limit you set against the real ceiling. Email and portal caps sometimes count the encoded attachment, which is larger than the raw file, so choosing 25 MB exactly for a 25 MB inbox can still bounce. Leaving a margin avoids a failed send.

Confirm the part count and each part's reported file count and size match what you expect, then actually open at least one part and extract it to verify the contents are intact and the folder paths look right. Look for the over-limit note on any part, which means one file was too large to fit. Make sure you downloaded every part, since a missing part means missing files for the recipient, and keep the naming sequence so they arrive in order.

When sharing, tell the recipient these are independent ZIPs to be extracted separately, not volumes to be rejoined. If your limit was set for a specific inbox or portal, send a test or re-check the platform's stated cap, allowing headroom for attachment encoding overhead.

For official submissions, check every required file against your source list across all parts; a missing part does not announce itself.