Create ZIP

Drop files in, name the archive, and download one ZIP. Nothing is transmitted. Of every tool on this site, this is the one where uploading is most obviously absurd — bundling files into a container is pure local bookkeeping, and yet every online ZIP service asks you to send them each file first.

Why this page exists at all

Consider what a server-side "create ZIP" service actually does. You upload ten files, which takes as long as your upstream connection allows. The server writes them into a container — an operation involving no analysis, no conversion, and no decision. Then you download the result, which is roughly the same number of bytes you just sent up. Two full transfers of your data to achieve something that requires no intelligence whatsoever.

The reason it works that way is not technical. It is that the site is built around a server, so everything has to go through the server. Once the work happens in the browser instead, the transfer disappears and so does every limit that existed to ration server capacity: no file size cap, no total archive limit, no tasks per hour, no account.

This is also the page to point at when someone doubts that browser-based file tools are real. There is no conversion here to argue about the quality of. Either the bytes come back out identical or they do not — and you can check by extracting the archive and comparing.

Why zipping photos does not make them smaller

ZIP compresses with an algorithm called deflate, which finds repeated byte sequences and stores each repeat as a short reference. That works extremely well on text, source code, CSV, XML, logs and uncompressed formats such as BMP or WAV, where the same patterns occur constantly.

It does almost nothing on JPG, PNG, WebP, MP4, MP3, PDF or DOCX, because those formats already removed their own redundancy. Their contents look statistically like random noise, and there is nothing left for deflate to find. Compressing them again typically produces a file a few bytes larger than the input, because deflate has to add its own block headers, while burning CPU time proportional to the file size.

That is why the default here is Automatic: files whose extension indicates an already-compressed format are stored without a second pass, and everything else goes through deflate. Each row in the file list tells you which treatment it got, so you can see the reasoning rather than wonder why the archive did not shrink. DOCX, XLSX, PPTX, EPUB, APK and JAR are worth calling out — those are themselves ZIP files with a different extension, which is why they are on the store list.

The practical consequence: if you are bundling twenty photos, the ZIP will be about the size of the twenty photos. That is not a failure. Wrapping them in one file for a single attachment or upload was the point, and pretending otherwise would be the dishonest part.

The Chinese filename problem, and where it comes from

Non-ASCII filenames in ZIP archives are a genuine mess, and anyone in a Traditional Chinese environment has hit it: you receive a ZIP, extract it, and every filename is unreadable rubbish.

The cause is historical. The original ZIP specification made no statement about which character encoding filenames use, so tools wrote whatever the machine's local code page was — Big5 in Taiwan, GBK in mainland China, Shift_JIS in Japan. A field for declaring UTF-8 was added much later, as bit 11 of the general purpose flag. Modern tools set it; older Windows tools, and anything written before roughly 2010, do not. When an archive with Big5 names is extracted by a program assuming UTF-8, or vice versa, every non-ASCII character becomes noise.

This tool writes filenames as UTF-8. That is the correct modern behaviour and is what macOS, Linux, current Windows and every browser expect. Two honest caveats: a very old extraction utility on a Chinese Windows installation may still misread them, and this is a property of the reader rather than something an archive can fix; and if you are dealing with a broken archive that somebody else made, no ZIP creator can help — that needs a re-encoding tool.

If a file has to survive an unknown recipient with unknown software, ASCII filenames remain the only guaranteed answer. That is an unsatisfying conclusion, but it is the true one, and knowing it beats discovering it after sending fifty files to a client.

What this tool does and does not do

Duplicate names are handled rather than silently swallowed. A ZIP directory is a flat list of names, and two identical entries are technically legal but will overwrite each other on extraction — which is entirely plausible when you drag one IMG_0001.JPG from each of two folders. Repeated names get a number appended, and the page tells you it happened.

Modification times are preserved from the original files, so extracting does not reset every date to now. That matters for photo backups, where the date is the only sort order anybody uses.

Three things are deliberately absent. There are no folders — everything goes in flat, because browsers hand a file input a list of files and not the directory structure they came from. There is no password protection: ZIP's original encryption, ZipCrypto, is broken and trivially cracked, and the stronger AES variant is a PKWARE extension that many extractors cannot open, so offering "password protected" here would be selling a feeling of security rather than security. And there is no split archive across multiple volumes, which is a floppy-disk-era feature that mostly causes confusion now.

Limits, both real and absent

We impose none. The real constraint is your device memory, because each file is read into memory and the finished archive is held there before download. A desktop browser handles a few hundred megabytes comfortably. A phone will give up sooner, and the failure looks like the tab reloading rather than a clear error message.

One format limit is worth knowing: the original ZIP format uses 32-bit size fields, capping individual files and total archives at 4 GB. Larger archives need the ZIP64 extension. If you are near that boundary you are outside what a browser tab should be doing anyway, and a desktop tool is the right choice.

The engine is fflate, a small MIT-licensed pure JavaScript implementation — no WebAssembly, and already used elsewhere on this site to bundle multi-file results. So this page added no new dependency at all, which is itself a small argument about how much machinery this job really needs.