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 the common ceilings: 5, 10, 20 MB (Outlook), 25 MB (Gmail), 50, and 100 MB (WhatsApp), plus a custom value for any portal or storage limit you specify.

Realistic fits include emailing a large project or document bundle in attachment-sized chunks, sharing a backup or photo album over WhatsApp where a hard per-file cap applies, and preparing parts for a government, university, or job-application portal that rejects oversized uploads. It also suits developers and office users who need to move a build output or asset folder past a transfer limit, and students or admins splitting a large submission into pieces that each clear a form's size rule.

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 exceed your limit — at which point it starts a new part. You then download each part individually or use Download all, and files are named after the original with a -part1.zip, -part2.zip suffix.

What it supports: ZIP input, and ZIP output as multiple complete archives. Files are recompressed with DEFLATE as they are repackaged. 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 shrunk to fit by splitting. The tool places such a file in its own part, which will exceed the target. If a part comes back larger than expected, an oversized member file is usually why — lower expectations rather than the size cap. Separately, already-compressed content (JPG, PNG, MP4, MP3, PDF, existing ZIPs) gains little from recompression, so the part total may sit close to the sum of the originals.

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 small 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. Check that no part unexpectedly exceeds your target — if one does, look for an oversized individual file inside it. 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, financial, or legal material, verify manually that every required file is present and readable across the full set of parts before submission. Because each part is a separate archive, an overlooked or undelivered part will not announce itself — a deliberate file-by-file check against your source list is the only reliable confirmation.