Convert 7Z to ZIP

The typical arrival at this page is not a choice about compression. Somebody sent a `.7z`, and the machine in front of you will not open it or the system you need to feed will not accept it — a portal that names ZIP in its help text, a shared drive that previews ZIP and shrugs at everything else, a laptop where installing an archiver needs a ticket.

ZIP solves that by being older and duller. PKWARE published it in 1989 and its specification, APPNOTE.TXT, has been public throughout; support was built into Windows and macOS long ago and into essentially every upload endpoint written since. It is not the better format by any technical measure, it is the assumed one, and being assumed is worth more than being good when the constraint sits on somebody else's machine. That is also why this conversion is worth doing even though it makes the file bigger — the alternative is not a smaller file, it is a file nobody can open.

The registry marks 7Z as solid and ZIP as not, and that flag is the whole size difference. A solid archive glues its members into one stream before compressing, so a phrase that appears in forty files is stored once and referenced thirty-nine times. Add a dictionary of up to 64 MB and the compressor can reach almost anywhere in a typical archive to find that repetition.

ZIP cannot do either. Each entry is deflated separately against a 32 KB window and then listed in a central directory, so forty similar files are compressed forty times from a standing start and the redundancy between them is paid for forty times over. Expect the ZIP to be noticeably larger where the 7Z held many similar documents, and barely larger where it held photographs or video that were compressed long before they were archived. If the difference turns out to matter — an attachment limit, a slow upload — the answer is usually a link rather than another format, because no container everything can open will compress like a solid one.

The property that costs ZIP its ratio is the same one that made it universal. Because every entry stands alone and a directory at the end says where each one is, a program can read one file out of a large archive without touching the rest, and can list the contents without decompressing anything.

That is what lets Explorer show you the inside of a ZIP as if it were a folder, and what lets a web application accept an upload and pull one member out of it. A solid 7Z has to be decompressed from the beginning to reach a file in the middle, which is fine for an archive you unpack whole and awkward for everything built around browsing.

Both formats support passwords, and neither can be converted while one is set. The unpacker on our converter is invoked with an empty password on purpose: a protected archive then fails at once with a readable message instead of blocking on a prompt that has no terminal to appear in.

The fix is on your side and it is short. Extract the 7Z locally with the password, then compress the resulting folder to ZIP — Explorer and the Finder both do that from the right-click menu. Nobody who cannot supply the password should be able to repack the archive, and this converter is not an exception to that.

This pair does not run in your browser. The archive is uploaded over an encrypted connection to our converter, 7-Zip extracts it into a scratch directory, and the contents are packed again as a ZIP from inside that directory so the result holds your files rather than a wrapper folder. The output is sent back and everything the job wrote is deleted when it ends.

That scratch space is a memory-backed filesystem of bounded size and it is discarded together with the container that used it. The limits that follow are 25 MB per file on the free tier and sixty seconds per job, after which the process is killed — long enough for any archive that fits the upload limit, and short enough that a deliberately malformed one cannot sit there spinning.

Both formats are real containers, so names, nested folders and full paths survive the round trip, and both carry checksums, so a damaged member is detected rather than quietly extracted. The members themselves are copied without being re-encoded; a lossless container has nothing to re-encode.

What can be lost is the container-level metadata that never lived inside the files: an archive password, and on some formats the original permissions and timestamps. If a build or a deployment depends on an executable bit, restore it after extracting rather than assuming the ZIP carried it.

The original ZIP design used 32-bit fields, which capped an archive and each member at 4 GB and the number of entries at 65,535. The ZIP64 extension in APPNOTE.TXT lifts all three, and current tools write it automatically when they need it.

Nothing you can convert on the free tier will approach any of that — the 25 MB upload limit arrives first by a wide margin. It is worth knowing anyway, because it is the reason very old software occasionally refuses a large modern ZIP, and the reason "ZIP is universal" is a statement about the common case rather than a guarantee.

If the archive is going into your own storage rather than out to somebody else, converting it makes the file bigger for no benefit. 7-Zip, Keka and PeaZip are all free and all read it, and the registry lists exactly those as the software for the format.

The conversion earns its keep when the constraint is at the far end and you cannot change it. That is a question worth asking explicitly before you convert: is the problem the file, or the machine in front of me? If it is the machine and you can install an archiver, that is the cheaper fix and it leaves the compression alone.

Once you have the ZIP, the usual obstacle stops being the format and becomes the size. Mail systems commonly refuse attachments in the tens of megabytes, and many of them look inside archives as well, so a ZIP containing executables or scripts can be rejected on its contents rather than on its extension. Repacking made the file larger, which means this conversion can occasionally turn a message that would have been delivered into one that is not.

When that happens the answer is a link rather than another archive format, and converting again will not help. It is worth separating the two failures because they look identical from the outside: converting to ZIP fixes "my software cannot open this", and nothing about the container fixes "your mail server does not want this". If the recipient can reach a shared drive or a file service, that path avoids both problems and has no size ceiling worth arguing with.

A repack is worth a glance before it goes anywhere, and both formats make that easy because both store checksums per entry. Open the ZIP, compare the number of entries and the paths against the 7Z, and confirm nothing arrived at a different depth than expected — the archive is written from inside the extracted directory, so your files sit at the root rather than under a wrapper folder, which may or may not be what the original looked like.

The one case that genuinely warrants a closer look is an archive holding empty directories. Both formats can record a directory with no files in it, and tools vary in whether they recreate one on extraction, so a structure that depends on an empty folder existing is the thing most likely to come out subtly different. If a build or an import expects that folder, create it explicitly rather than trusting the archive to carry it.