How it works : Zip and unzip
The browser can compress, but it can neither work out a CRC-32 nor write a zip container: both of those are written by hand here, and the archive we produce is REOPENED by our own reader before it is handed to you.
Zipping three files to attach them to an email is an everyday gesture, and it is one of the cases where online sites are at their most intrusive: they receive the whole of what you were about to send, often administrative documents or family photographs. The browser, meanwhile, can do all of it without sending anything.
It can compress and decompress with the so-called raw deflate function, from Chrome 103, Firefox 113 and Safari 16.4 onwards. What it cannot do is work out the check value a zip archive requires for each of its entries, nor write the container itself. Both of those pieces are written by hand in this tool, copied from our icon generator which already had them: we do not reinvent a format we have already written here.
And the tool reads itself back. Having built your archive, it REOPENS it with its own reader, decompresses every entry and RECALCULATES its check value. An archive no software could open is a false result, and without that reading back it would be you who found out, in front of your recipient.
How it works
- To archive, drop several files in at once: the tool lists them, compresses them one by one and hands you an archive.
- To open, drop a single archive in: the tool shows what it holds, with the real size of each entry, and you choose what to extract.
- The direction works itself out, not from the extension but from the first bytes of the file: an extension can be renamed, a signature cannot.
Formats accepted
Any files at all to build an archive; a single zip archive to open one. The mode is worked out from the FIRST FOUR BYTES of the file you drop in, not from its name.
Any files at all, to archive
Drop in as many as you like at once. Each is compressed separately, and compression is only used when it genuinely saves room: on a JPEG or an already compressed PDF it would produce a BIGGER stream, and the entry is then stored as it is.
A zip archive, to open
Stored entries and deflate-compressed entries are both read, which covers very nearly every real archive. ENCRYPTED entries are named and set aside, and Zip64 archives are refused out loud. The threshold comes from the format's reference document: more than 65,535 entries, or a size beyond four gigabytes.
Its limits
200 MB per file
Browser compression works in memory, and the whole archive has to fit there alongside the original files. Past that, a phone short of memory crashes the tab instead of returning a result: the limit is announced, and the tool refuses cleanly.
A password-protected archive will not open here, and we do not make one
Two separate reasons. On opening: the format's historic encryption has been broken since 1994 by a known-plaintext attack published by Eli Biham and Paul Kocher (we have not read the paper, only its reference); the modern one is a WinZip extension in two variants, AE-1 and AE-2, documented by the vendor itself, differing only in how they treat the check value. So we name encrypted entries and set them aside rather than half-decrypting one. On writing: to actually protect a file, the “Encrypt a file” tool in the security corner does better, with its whole method on display and six hundred thousand key-derivation rounds, which no zip does.
Zip64 archives are refused, and it is said
Beyond 65,535 entries or four gigabytes, the format keeps its counters in an extra record and the usual fields saturate at their maximum value. We do not read that record: rather than return a half-read archive, the tool says it cannot read it. An archive of that size is well past the weight limit anyway.
A download cannot recreate folders
A browser sends down files, not directory trees. An entry filed inside a subfolder therefore comes back out with its path flattened into the name, and the tool says so. That is also what defuses the trap of paths climbing out of the extraction folder: we strip the climbing segments and flag it, rather than relying on the browser to protect us.
Extracting several entries asks the browser for permission
On the second file downloaded from a single gesture, Chrome asks for the “download multiple files” permission: its source code sets the limit at fifty simultaneous downloads and remembers your answer until the address changes. Firefox, for its part, tried to build the same safeguard and never shipped it, as its own bug tracker says. For Safari we found no first-hand source. This cannot be worked around and we do not try to: the sends are spaced 350 milliseconds apart, and you can always extract one entry at a time.
The archives we write carry no date
A zip normally records the time of each entry. That would be the only piece of information about you the file would carry, when neither the recipient nor the format needs it. So we write the oldest date the format allows, 1 January 1980: two archives made of the same files are identical byte for byte. It is the same decision as for the icon archive in the image corner.
Questions about this tool
Are my files sent anywhere?
No. Open the inspector with the F12 key, go to the “Network” tab, clear the list, then drop your files in and build the archive: nothing leaves. Cut your connection and do it again, the tool still works. It is the most important point on an archiving tool, because what people put into one is generally everything they were about to send.
Why is my archive almost as heavy as my files?
Because your files are probably already compressed. A JPEG photograph, a PDF, a video, a modern office document: all of them already contain compression, and there is nothing left to gain on them. The tool tells you line by line, and it stores those files as they are rather than making them BIGGER, which is what compressing them a second time would do. What compresses well is text, older spreadsheets, code files, lossless images.
What exactly is this reading back the page talks about?
Having written the archive, the tool reopens it with its own reader, as another piece of software would: it finds the directory, walks the entries, decompresses each one and recalculates its check value from the bytes obtained. An archive can have an impeccable structure and a wrong check value: it would pass every structural test and fail at your recipient's end. It is the same requirement as everywhere on this site: we read the file we produced, we do not take the tool's word for it.
Why do the extracted files not have their folders?
Because a browser sends down files, not directory trees: it has no way to create a folder on your device, and that is a good thing. An entry filed inside a subfolder therefore comes out with its path flattened into its name, which keeps the information without inventing a structure. That is also what makes an old archive trap harmless: an entry whose path climbs out of the extraction folder cannot write anything elsewhere, and we clean its name regardless.
Why does the browser ask permission when I extract several files?
Because a site triggering several downloads from one click is behaviour browsers are suspicious of, rightly. The “download multiple files” permission is asked once, and granting it is riskless here since the files come out of your own archive. We space the sends three hundred and fifty milliseconds apart, which stops them cancelling each other, and you can always extract one entry at a time.
Could you add password protection?
We do not plan to, and for a reason of substance. The historic encryption of zip archives has long been considered broken; the modern one is a proprietary extension of the format, with several variants and differences between programs. So we would do heavy work to deliver a protection we could not honestly call strong. The encryption tool in the security corner solves the real problem: it shows its whole method, it uses six hundred thousand key-derivation rounds, and the file it produces is decrypted on the same page.
Can I add a file to an existing archive?
Not directly: the tool opens an archive or builds one, it does not modify one. The way through is to extract what you want, then drop it all back in together with the extra file. That is one more gesture, but it avoids a whole class of nasty surprises: an archive edited in place can keep traces of its previous contents, and a tool promising to “update” an archive without rewriting it entirely is not as clean as it looks.
The browser can compress, but it can neither work out a CRC-32 nor write a zip container: both of those are written by hand here, and the archive we produce is REOPENED by our own reader before it is handed to you.
VerifyThe proof, step by stepThe network inspector check, explained one gesture at a time, with screenshots.
The cornerThe everyday cornerConvert units and see where every factor comes from, work out dates without being tripped up by a clock change, trim a recording, zip a folder. The tools you look for once a month and never find again.