ZIP vs 7Z

Windows, macOS, Linux, Android and iOS all create and open ZIP archives with nothing installed. Every email client, every upload form, every browser and every programming language handles them. That is more than three decades of ubiquity and it is not a small thing to give up.

7z needs software. 7-Zip on Windows, Keka or The Unarchiver on a Mac, p7zip elsewhere — all free, all a two-minute install, and all a step the recipient has to take before they can see what you sent. Every other difference in this comparison is measured against that one.

Substantially, on the right material. The LZMA2 algorithm looks much further back through the data than ZIP’s Deflate does, so on text, source code, logs, databases and uncompressed images it routinely produces archives thirty to fifty per cent smaller.

On the wrong material it produces almost nothing. Photographs, music, video, PDFs and Office documents have already had their redundancy removed, so three different JPEGs totalling 31 kilobytes came to 25,576 bytes as a solid 7z and 26,173 as a ZIP — a difference of two per cent. Since that is what most people are actually zipping up to send, the practical difference in everyday use is often zero.

The exception is repetition. Three copies of the same 8,924-byte JPEG make a 26,383-byte ZIP, because Deflate begins again at every file, and an 8,876-byte solid 7z, because LZMA2 recognises the second and third copies as data it has already read. There is nothing left inside a compressed file for either algorithm to find, but a repeated file is a different kind of redundancy, and it is the one case where a folder of JPEGs does shrink.

Part of 7z’s advantage comes from treating the whole archive as one continuous stream rather than compressing each file separately. Redundancy between files is then available to the compressor, which is why a thousand similar log files shrink so dramatically.

The cost is extraction. Pulling one file out of a solid archive means decompressing everything up to it, so opening a single document from a large solid 7z is slow in a way that ZIP never is. For an archive somebody will browse, this is a genuine drawback; for a backup that is only ever extracted whole, it is free.

Both formats can encrypt. ZIP’s original scheme is broken and has been for decades — a dozen known bytes of any one file in the archive recover the keys to all of it, and the predictable header of a JPEG or a DOCX supplies them. Modern tools can write AES-256 into a ZIP, but support for reading it is inconsistent, and Windows Explorer will not.

7z uses AES-256 by default and can additionally encrypt the file names, so an observer cannot even see what the archive contains. If files are being protected rather than merely bundled, 7z is the better answer — and the password remains the weak point in either format, because a weak password defeats any encryption at all.

Both are single points of failure. A corrupted byte in the middle of an archive can cost you everything after it, and in a solid 7z it can cost you the lot. Neither format carries error correction, so cloud sync, a bad cable or a failing drive is not recoverable from within the file.

ZIP degrades slightly better, since each file is compressed independently and a damaged archive often gives up most of its contents to a repair tool. If archives are being kept rather than sent, the answer is not choosing between these two but keeping a second copy, and ideally a checksum recorded separately.

Sending something to another person: ZIP. Always. The saving from 7z is rarely worth an email that begins with "you need to install something first", and on the photographs and documents most people send there is no saving at all.

Storing or moving a large amount of compressible data — logs, source, database dumps, disk images, a corpus of text — 7z, and the difference is worth real money in transfer and storage. Same for anything encrypted, where ZIP’s legacy scheme is not a serious option.

And on macOS, one practical note: the built-in archiver adds hidden metadata files that Windows users then see as clutter inside the archive. It is cosmetic, it looks like a fault, and a third-party archiver avoids it.

RAR is the third name in every conversation of this kind and it is the one to avoid for anything you create. The format is proprietary: creating an archive requires licensed software, and free tools can only extract. That is precisely the position 7z occupies without the licence.

It does have genuine recovery records, which is a real feature neither ZIP nor 7z offers. But receiving RAR files and creating them are different decisions, and there is no good reason to produce one today.

The ZIP format predates Unicode, and its original design stored filenames in whatever code page the machine happened to use. A flag was added later to declare UTF-8, but not every tool sets it and not every tool reads it.

This is why an archive made on a German or Japanese machine can unpack elsewhere with mangled filenames — the accents and characters replaced by symbols — while the file contents are perfectly intact. 7z has stored names as UTF-16 from the start, with no flag and no code page to guess at, and does not have the problem. If you are packing filenames with anything beyond plain ASCII in them and the recipient is on another system, that is a genuine reason to choose the newer format.

The compression advantage comes largely from a much larger dictionary — the window of already-seen data the algorithm can refer back to. ZIP's is 32 kilobytes. 7z's default runs to 16 or 64 megabytes, and its highest settings go considerably beyond that.

That memory has to be available when unpacking, not only when packing, and roughly in proportion. An archive made at the maximum setting can need well over a gigabyte to open, which is fine on a desktop and is not fine on a small server or an older machine. Packing at the highest level a machine can manage is not automatically the right choice when somebody else has to open it.