How to Zip and Unzip Files on Mac (Built-in Tools First)

A .rar lands in your Downloads folder. You double-click it and TextEdit opens a page of garbage, because macOS handed the file to whatever app claimed the extension. The same thing happens with .7z, on a machine that has been compressing and expanding files without complaint for years.

The archive tools are all there. Finder exposes about a third of them, and the third it exposes is the one you already know. The built-in set will cover most of a week's worth of files once you know which one does what. Knowing where it stops is the difference between two minutes and an afternoon of installing things at random.

Right-click, Compress, and what just happened

Select a file or a folder in Finder, choose Compress, and you get one .zip beside the original. The original stays where it was, so the folder now exists twice and you delete the archive when you're done with it. Select several items at once and the result is called Archive.zip, a name you will regret in a month.

Finder isn't doing the work. It hands the job to Archive Utility, a small app at /System/Library/CoreServices/Applications/Archive Utility.app that most people have never opened. Its Info.plist lists what it reads: ZIP, TAR, TAR inside bzip2, bzip2, gzip, cpio, and the old uuencoded format. Double-click any of those and it expands into a folder named after the archive, sitting beside it.

That list is the whole built-in story, and it explains the first surprise. No RAR entry, no 7z entry, no xz. A stock Mac also has no unrar and no 7z command to fall back on. Nothing is broken. Those formats were never included.

Six jobs the built-in tools won't do

Making anything other than ZIP is the first. There's no .7z, no .tar.gz, no .rar anywhere in the Finder interface, and the Compress command has no format menu at all.

Opening RAR, 7z or xz is the second, and it's usually where the search for other software starts. Renaming a .rar to .zip changes nothing about the bytes inside. The file still isn't a ZIP, and Archive Utility still can't read it.

Taking one file out of a big archive is the third. Press Space on a .zip and Quick Look lists what's inside, which answers whether the file you want is even in there. Extracting just that file without expanding the other four gigabytes takes the Terminal.

Adding a password is the fourth. The Compress command has no password field, no options dialog, and no preferences tab hiding one. ZIP has carried password encryption for decades. Finder doesn't offer it.

Splitting an archive small enough for an upload cap is the fifth. Mail servers and contact forms reject by size, and nothing in Finder can produce smaller pieces instead of one large file.

Leaving macOS clutter out is the sixth. A folder you have ever opened in Finder holds a .DS_Store file, and a plain recursive zip includes it. Verified on this machine: a folder with one hidden .DS_Store zipped to five entries, and the same command with an exclude pattern zipped to four.

The Terminal lines that cover most of it

None of this needs a download. Every command below shipped with macOS 15 and belongs to the Info-ZIP build Apple has been bundling for years, zip 3.0 and unzip 6.00.

One file out of an archive, without unpacking the rest:

unzip -l big.zip

unzip big.zip "Sub/report.pdf" -d ~/Desktop

The first prints the listing. The second extracts that path and nothing else. Match the string against what the listing shows, because the paths inside won't always match the folder names you were expecting.

A ZIP with a password:

zip -er private.zip Folder

The e prompts for a password and the r includes everything below the folder. Read what zip's own help says about that switch: standard (weak) PKZip 2.0 encryption, with the word in brackets coming from Apple's build and not from me. It keeps a file away from a curious colleague. It isn't what you use for a passport scan, and the encrypted disk image route is the honest option for anything that matters. Avoid -P password, which works and also writes the password into your shell history.

An archive of parts:

zip -s 100m -r parts.zip Folder

Verified with a small test file and -s 64k: the output is parts.z01, parts.z02, parts.z03 and parts.zip, with the last piece carrying the name you chose. Whoever receives them needs all of the pieces in one folder before double-clicking the .zip.

A damaged archive, before you give up on it:

zip -F broken.zip

zip -FF broken.zip --out salvaged.zip

Those are zip's own repair switches, described in its help as an attempt to fix a mostly intact archive and an attempt to salvage what can be read. They work on a truncated copy far more often than people expect, and the second one is worth trying on a file you were about to throw away.

A tarball, which Archive Utility opens too. tar -czf backup.tar.gz Folder makes one, tar -tzf backup.tar.gz lists it, tar -xzf backup.tar.gz expands it.

Why a ZIP of photos hardly shrinks

Compression and shrinking are different jobs, and ZIP is worse at the second than most people expect. JPEG, PNG, MP4 and HEIC files are already compressed. Run them through deflate again and it finds almost nothing to remove, which the tool will tell you if you watch its output. A 200 KB file of random bytes went into a test archive here and came out marked as deflated by zero percent. That's the same result a photo gives.

So when the goal is a smaller file instead of one bundle, the archive is the wrong tool. Shrinking images, video and PDFs has its own set of tools, covered in the compression guide from September.

The .cpgz loop, and three other shapes of failure

Double-click an archive and get a file called something.zip.cpgz. Double-click that and you get the original .zip back. The loop is Archive Utility trying to expand something it can't read, then compressing the result back up with gzip, because cpgz is gzip. The extension was wrong for the real format. Renaming it back and opening the file in something that reads the actual format ends the loop.

A truncated download is the next shape. The archive opens partway and then complains, or reports checksum trouble on the files near the end. Compare the size against what the sender says it should be before hunting for a more interesting cause.

An empty folder after an expansion that looked successful usually means encryption. The archive asked for a password and got one typed too quickly, or it asked and was cancelled. A ZIP with legacy encryption will sometimes finish without a word of complaint, which is a confusing way for it to behave.

Missing files from an archive that expanded fine means it was split. Parts two and three have to sit beside part one before any of it unpacks, and the error message rarely says so.

Sending an archive to someone on Windows

Two pieces of macOS clutter make a perfectly good archive look broken to a Windows recipient, and the advice most likely to be repeated makes one of them worse.

The first is .DS_Store, Finder's folder memory. Exclude it: zip -r project.zip Project -x "*.DS_Store".

The second is the __MACOSX folder full of ._ files, which carry resource forks and extended attributes. It appears because the tool that preserves Mac metadata is the tool that writes them. Verified here: one folder zipped with the plain command produced four entries, and the same folder zipped with ditto -c -k --sequesterRsrc --keepParent produced fourteen, seven of them __MACOSX bookkeeping. The ditto form suits Mac to Mac, where permissions and resource forks matter. Anything crossing to Windows is better off without it.

Whichever you use, list the archive before it leaves. unzip -l takes a second and it's the only way to know what the other person will actually see when they open the folder. Moving files between the two systems has its own guide, and the cable, filesystem and line-ending traps in it are worth reading before a big transfer rather than after one has gone wrong.

Where an app earns its place

The gaps above have a shape: three formats macOS won't touch, one password field it refuses to show, and one listing you can't act on without the Terminal. PressZip covers all four. It opens ZIP, RAR, 7z, TAR and gzip in one app, which ends the format roulette. It shows what's inside. Pull out only what you want. It makes ZIPs from dropped files or folders with an optional password, and it opens the encrypted ones other people send you. Recents, Open With and Reveal in Finder handle the small friction that makes an archive annoying rather than hard.

Two limits, stated plainly. It produces ZIP only, so RAR and 7z can be read here and not written. And it runs on macOS only today, with no Windows build on the menu, which matters if a second machine is part of how you work. Its comparison with WinRAR covers the rest of the detail.

What no app changes is the encryption question. A password on a ZIP is the format's own protection whatever wrote it, so the folder-level encryption guide is still where you go for a file you would call confidential.

When the bundle itself is too big to send

The remaining case is the attachment that won't attach. The archive is fine and the size isn't. TinyImage re-encodes images smaller and leaves the dimensions alone, free on both platforms. TinyPDF writes a smaller copy of a PDF beside the original with text still selectable and links intact. TinyVideo does the same job for clips. When the file has to stay the size it is, FileShipper moves it over your own network to a phone or another computer, with nothing uploaded and no software to install on the receiving device.

A minute-long routine

1. Name the archive for the person receiving it. Archive.zip is unopenable in a year.
2. Right-click Compress for anything that stays on a Mac.
3. For Windows, add -x "*.DS_Store" and list the contents before sending.
4. For a password, use zip -er and send the password by a different route than the file.
5. For RAR or 7z, don't rename the extension.
6. Delete the archive after the send. It's a delivery format, not a filing format.

That last habit earns more space back than any of the tools, and the disk space guide starts with exactly the Downloads pile, while DiskBrew will show you how much of it you are carrying.

One menu, one subscription

getapps.cafe is 128 native apps for macOS and Windows, and 105 of them install on Windows too. Solo Cup is $3.99 a month or $1.99 a month billed yearly at $23.88, for one computer. Family Roast is $7.99 a month or $3.99 a month billed yearly at $47.88, for up to five, and each computer you sign in on takes one licence slot that frees the moment you remove that device. The 7-day trial adds a card when it starts and charges nothing until it ends.