Convert ZIP to 7Z

The reason is almost always storage or transfer rather than compatibility. A ZIP is what a tool handed you — an export, a download, a batch somebody assembled on a Windows machine — and it is now going somewhere that charges for bytes or is meant to sit untouched for years. 7Z is the format to reach for when the archive has exactly one owner and no audience, which is a much narrower situation than the number of pages recommending it would suggest.

That framing decides whether the conversion makes sense, and it is worth answering honestly before uploading anything. If the file is going to a colleague, a client or an upload form, ZIP is what every operating system already opens and the saving is nowhere near worth the support call it will generate. If it is going to a backup drive, an object store or your own machine in three years, the smaller file wins outright and nobody else needs to know which format you chose. Size matters to the decision too: under a few megabytes the difference is kilobytes and not worth the trouble, while at hundreds of megabytes repeated across a folder of archives it becomes the difference between one storage tier and the next.

The difference is the window the compressor can look back through. ZIP, defined by PKWARE in 1989 and standardised as APPNOTE.TXT, deflates each entry independently with a 32 KB history — so a phrase repeated three files apart is compressed three times from scratch. 7Z, from 1999, uses LZMA2 with a dictionary that the registry records at up to 64 MB, two thousand times the reach.

That is why the gap is widest exactly where people notice it: forty near-identical spreadsheets, a source tree, a folder of log files, a set of exports that differ by a date column. On a ZIP holding one MP4 or a handful of JPEGs, both compressors have already lost — the data was compressed before it was archived, and neither can find redundancy that is not there.

The registry marks 7Z as solid and ZIP as not, and that single flag is most of the size difference. A solid archive concatenates the members into one continuous stream before compressing, so the compressor sees the whole set at once instead of restarting at every file boundary.

The cost arrives when someone wants one file back. In a ZIP, each entry is independently compressed and can be pulled out on its own; in a solid 7Z, everything before the file you want has to be decompressed first. For an archive that is opened whole, or rarely, that is free. For one that is browsed and picked at daily, it is a genuine annoyance.

The registry lists patchy support as a known problem for 7Z, and that is not a footnote — it is the deciding factor for most people who land here. Windows Explorer and the macOS Finder both unpack ZIP with nothing installed. Neither opens 7Z. Sending one to a recipient you cannot instruct is how an archive becomes an email thread.

The same applies to anything automated at the far end: upload forms, ticketing systems, learning platforms and print shops overwhelmingly accept ZIP and refuse everything else. If any of that is in the path, the correct answer to "should I convert this" is no, and this page would rather say so than take the click.

The files themselves are safe — this is a lossless repack and every member comes out unchanged. What is at risk is the metadata the old container carried about them rather than inside them: an archive password, and on some formats the original permissions and timestamps.

Encryption is the clearest case. A ZIP protected with a password cannot be read without it, so the job fails rather than guessing; the extractor is invoked with an empty password specifically so it reports the refusal instead of hanging on a prompt that has no terminal to appear on. Unlock the archive locally, then convert the plain one.

This conversion does not run in your browser. Most of the tools on this site keep the file on your device, and repacking archives is one of the exceptions: the file is uploaded over an encrypted connection to our converter, unpacked and repacked with 7-Zip, and sent back. It is deleted the moment the job finishes, and the scratch space it used is thrown away with the container.

The practical limits follow from that. The free tier accepts 25 MB per file. Any single job is killed after sixty seconds, because a malformed archive tends to put a compressor in a loop rather than making it fail. If the archive holds something you would not send to a third party at all, 7-Zip on your own machine does the same repack offline.

Both formats are containers with a real directory of entries, so nested folders, long paths and file names survive intact. The repack happens from inside the extracted directory rather than one level above it, which is the difference between an archive holding your files and an archive holding a single folder that holds your files.

Checksums are carried by both formats, so a corrupted member is detected rather than silently unpacked. The downloaded file takes your original name with a `.7z` extension — `invoices-2025.zip` comes back as `invoices-2025.7z` — and its contents list should match the ZIP entry for entry.

A one-megabyte ZIP can honestly declare that it expands to terabytes, which is the oldest trick in the archive book. Before anything is written to disk, the archive is asked what it claims to contain, and a total above 2 GB is refused with a plain message rather than an unpacking that fills a disk.

That check is not airtight on its own, because an archive can under-report and only reveal itself midway. What actually bounds the damage is the arrangement around it: the job directory is a memory-backed filesystem of fixed size, the process is killed at sixty seconds, and the container is discarded after the job. Worth knowing if you are converting an archive whose provenance you are unsure of.

XZ uses the same LZMA family and the registry gives it the same 64 MB dictionary, so on raw ratio the two are close and neither will surprise you. The difference is structural rather than mathematical: 7Z is a container that holds many members, each with a name, a path and a checksum recorded in the archive itself, while XZ compresses exactly one stream and knows nothing whatsoever about files. Everything a directory listing shows you about an XZ archive comes from a TAR hidden inside it.

For an archive meant to stay browsable, 7Z is the right end of that choice. You can list it without unpacking it, a future you can pull one file out without a two-step unwrap, and the format carries encryption and per-entry integrity data of its own. XZ belongs to the Unix convention where TAR carries the names and the compressor only makes the result smaller — a different job for a different reader, and the reason both formats still exist despite sharing a compression engine.

The temptation after any repack is to delete the original immediately, and the temptation is worth resisting for one minute. Open the 7Z and compare its entry list against the ZIP: same count, same paths, same sizes. Both formats store checksums, so an archiver will tell you if a member is damaged rather than handing you a corrupted file quietly, and 7-Zip has a dedicated test command that verifies every entry without extracting anything to disk.

The specific thing to look for is the top level. An archive written from a parent directory carries a leading folder in every path and one written from inside does not; the repack here packs from inside the extracted directory, so your files sit at the root of the new archive. If that is not what the ZIP looked like, the difference is real and it is better noticed now than by a script six months from now that expected one more level of nesting.