A zip made on a Mac that will not expand

Double clicking the archive produces one of three outcomes, and none of them is the folder that was expected. An error dialog appears with a number in it. A file with a .cpgz extension shows up next to the original. Or something briefly happens and nothing is there afterwards. Each of those is a different fault, and the usual advice, which is to download the file again, only fixes one of them.

The useful move is to stop clicking and spend two minutes determining whether the archive is intact. That single answer splits the problem in half, and each half has a short list of causes.

Three commands that answer the first question

The graphical route gives one bit of information: it worked or it did not. The command line tools that ship with macOS give the reason, and they are already installed.

Listing the contents reads only the directory at the end of the archive:

unzip -l archive.zip

A clean listing means the structure survived, whatever else is wrong. An archive that has been truncated fails here with a specific message about the end of central directory signature not being found, along with a note that the file may be one disk of a multi part archive. That message is the signature of an incomplete file rather than a corrupted one.

Testing goes further and verifies each entry:

unzip -t archive.zip

A healthy archive answers with a line per entry followed by a summary reading that no errors were detected in the compressed data. Anything else names the entry that failed, which is more useful than it sounds: a single bad entry in an otherwise valid archive usually means a storage fault at the source, not a transfer problem.

The third command is the one that matches what the Finder actually does, because the Finder's expansion goes through the same underlying tool:

ditto -x -k archive.zip destination_folder

On a truncated file this reports that it could not read the pkzip central header. When ditto fails and unzip succeeds on the same file, the archive is fine and the problem is in what the archive contains rather than in the archive itself.

The .cpgz file, and why it appears

The loop where a zip expands into a .cpgz and the .cpgz expands back into a zip has a simple explanation that is rarely stated plainly. The cpgz extension is not an error marker. It is a format that the archiving tool on macOS writes, a gzip compressed cpio archive, and it is what that tool produces by default when asked to create an archive rather than expand one.

Launching the archiving tool directly on a folder demonstrates this: the result is a .cpgz file, not a zip. So a .cpgz appearing next to a zip means the tool concluded that the input was not an archive it could read, and fell back to its other job, which is to compress the input it was given.

That reframes the fix. The question is not how to open a .cpgz. The question is why the zip did not read as a zip, and the answer is almost always one of three things. The download is incomplete, so the directory at the end of the file is missing. The file is not a zip at all, because a server sent an HTML error page with a .zip filename. Or the browser already expanded it once, leaving something that is no longer an archive but still carries the extension.

Checking the size against what the sender reports catches the first. Opening the file in a text editor and finding readable HTML at the top catches the second.

The third case is worth knowing because it produces a file that looks wrong and is not. A browser set to open safe files after downloading expands the archive on arrival and can leave the expanded result carrying a name that still ends in .zip. Double clicking that hands an ordinary folder or file to the archiving tool, which does the only thing it can do with something that is not an archive: it compresses it. The .cpgz is the honest output of that instruction.

Running file against the archive settles part of this in one step, because it reports the type from the leading bytes rather than from the name. An answer beginning with Zip archive data confirms the extension is telling the truth, and it also prints the minimum version needed to extract. It does not confirm that the rest of the file arrived, since a truncated download still starts with a valid signature, which is why the integrity test above stays necessary.

Failures that are about the destination

Some expansions stop for reasons that have nothing to do with the archive. Apple's own guidance points at the first of them:

If you can’t open the .zip file, make sure you have enough space on your Mac for the unzipped item. If you received the .zip file from someone else, there might be a problem with the file. Ask them to zip the file again and resend it. Source: support.apple.com

Free space is easy to underestimate because compressed archives hide their true size. A folder of text, source code or uncompressed images can expand to several times what the archive occupies, and the expansion needs room for the archive and the result at the same time.

Write permission on the destination is the second. Expanding into a folder that the current account cannot write to, or onto a disk image or network share mounted read only, fails with a permissions error rather than an archive error. Expanding into the home folder first and moving the result afterwards eliminates this as a variable.

The third is quieter. An archive downloaded through a browser carries a quarantine attribute, and expansion is allowed but the results inherit the same attribute. That is not a failure to expand, though it does produce the impression that something went wrong when the expanded application refuses to launch.

Archives that are intact and still beyond the bundled tools

An archive can pass every integrity check and still refuse to open, because it uses a feature the included tools do not implement. Two lines from the format specification explain the mechanism.

Every entry records the minimum version needed to read it, and the specification maps those values to features: 2.1 for Deflate64 compression and 5.1 for AES encryption. The tool reads that field, finds a requirement it does not satisfy, and stops.

Reading the field takes one command:

zipinfo -v archive.zip | grep -iE "minimum software version|compression method"

A normal archive reports a low version and a compression method of deflated or stored. An archive built by a Windows tool with stronger settings can report something higher, and that number is the whole explanation.

Password protected archives split along the same line. The traditional zip encryption works with the bundled tools, and unzip -P or ditto --password will open one. The newer AES based scheme, which several Windows archivers now use by default, is not implemented in the version of UnZip that macOS ships, which is 6.00. In that case the password is not wrong. The tool cannot attempt it.

Size is the last ceiling. The original format holds a four byte size field, which caps entries at just under 4 GB and the entry count at 65,535, and the Zip64 extension exists to lift both. Modern tools write Zip64 automatically when needed, but an archive that crosses those thresholds will not open in anything older.

The entry count is the limit that catches people out, because it is reached by thousands of small files rather than by anything obviously large. A project folder full of dependencies or a photo library with sidecar files passes 65,535 entries long before it passes 4 GB, and the archive that results is valid but demands a reader that handles the extension. Splitting that kind of folder into several archives, or wrapping it in a disk image instead, avoids the question entirely.

When the archive came from a Windows machine

The reverse direction has its own failure, and it looks like a corruption problem when it is not one. Filenames written by an older Windows archiver are stored in a legacy code page rather than UTF-8, and the bundled tools on macOS have no option for choosing how to read them.

The unzip binary included with macOS is Info-ZIP UnZip 6.00 with Apple modifications. Its options include -UU for disabling the use of stored UTF-8 paths, and nothing for nominating a different character set. Some Linux distributions ship a patched build with a charset flag; the macOS build is not one of them.

The result is names full of replacement characters, and files that cannot be opened afterwards because the name on disk does not match what anything expects. The archive is intact. Every byte of content is correct. Only the names were interpreted with the wrong rule, and no switch in the bundled tools changes that rule.

The realistic options are asking the sender to rebuild the archive with ASCII names, or extracting with an archiver that offers an encoding choice. Renaming afterwards is possible but tedious once more than a handful of files are involved.

There is a way to tell this apart from a genuine fault before extracting anything. Listing the archive shows the same broken names, which means the problem is in the stored names rather than in the extraction. If the listing is readable and the extracted names are not, something happened during writing instead, and the destination volume is the thing to look at. A volume formatted for Windows compatibility has its own rules about which characters a name may contain, and it can reject or alter names that the archive holds perfectly well.

Working through this without three windows

Every step above is a short command run against a file that is visible in a folder window. In practice that means switching to a terminal, typing or dragging the path, reading the output, then switching back to look at the result. For one archive it is nothing. For a batch of archives from a client, the switching costs more than the diagnosis.

Keeping the folder listing and the command line in the same place removes that overhead, which is the arrangement a file manager with a built in terminal provides. Where that sits relative to two pane managers and transfer clients is covered in the comparison, and common questions about the setup are answered in the FAQ.

What to change first

Run unzip -t on the archive before doing anything else, because that one result decides which half of this page applies. If it reports no errors, stop trying to repair the file and look at the destination, the encryption method and the version field instead. If diagnosing archives is a regular part of the work, having the terminal in the same window as the folder is what Atriens is for.