How to Password Protect a ZIP File on Mac

Sending a sensitive file over email or cloud storage? Wrapping it in a password-protected ZIP adds a real, practical layer of protection — the recipient needs the password to open the contents, even if the file ends up forwarded to the wrong person or sitting in a shared Dropbox folder longer than intended. Here's exactly how to do it on macOS, the tradeoffs of each method, and how strong this protection actually is.

Does macOS support this natively?

Partially, and this trips people up. Finder's built-in "Compress" option (right-click any file or folder → Compress) creates a ZIP file just fine, but there is no option anywhere in Finder's UI to add a password to it. That capability only exists through Terminal or a dedicated third-party app — a detail Apple doesn't make obvious, since the Compress option looks complete on its own.

Method 1: Terminal (built-in, but fiddly)

macOS ships with the same zip command-line tool used on Linux. Open Terminal and run:

zip -e -r archive.zip /path/to/your/folder

The -e flag triggers an interactive password prompt (typed twice, to confirm). This genuinely works and requires no extra software. The friction is real, though: you need the exact file path, the syntax is easy to get wrong (forgetting -r for a folder, for instance, will silently compress nothing inside it), and there's zero visual feedback while it processes — just a blinking cursor until it's done, with no progress bar for large folders.

Method 2: A free Mac archive app (recommended for most people)

A proper archive utility gives you a password field directly inside the compression dialog — select your files, choose ZIP format, type a password, click compress. With Unzipr, this is completely free with no paywall: there's no premium gate on basic password-protected ZIP creation, since it's a core extraction/compression task rather than an advanced feature.

This matters in practice because password-protecting an archive is the kind of task most people need only occasionally — maybe a few times a year — and don't want to relearn a command-line flag for each time. A persistent password field in a GUI removes that "wait, what was the syntax again?" friction entirely.

How strong is ZIP password protection, really?

This is worth being honest about. Standard ZIP encryption (sometimes called "ZipCrypto," the original encryption scheme built into the format in the 1990s) is better than sending the file unprotected, but it has known cryptographic weaknesses — particularly to a "known-plaintext" attack if an attacker has access to even one unencrypted file that also exists inside the archive. With modern compute power, ZipCrypto-protected archives can be cracked in a realistic amount of time by a determined attacker with the right tools.

Some newer ZIP tools support AES-256 encryption within the ZIP container itself, which is much stronger — but compatibility varies, since older ZIP readers (including some versions of Windows' built-in extractor) may not support AES-encrypted ZIPs correctly.

For genuinely sensitive data — financial records, legal documents, anything you'd be uncomfortable with leaking — consider 7Z format instead. 7Z's encryption is AES-256 by design, with no legacy weak mode to accidentally fall back to, and it's also available as a one-click compression option in the same archive apps that handle ZIP.

Step-by-step: password-protecting a ZIP with a GUI app

• Select the file or folder you want to protect in Finder, or drag it directly into your archive app
• Choose ZIP as the output format (or 7Z, if you want stronger AES-256 encryption from the start)
• Enter and confirm a password in the compression dialog before starting
• Choose your destination folder and start compression
• Test the resulting archive yourself before sending it — extract it once using the password you just set, confirming it works correctly, rather than assuming it's correct and finding out only when your recipient reports a problem

That last step matters more than it might seem: a mistyped password during creation is one of the more common reasons a recipient reports "the password doesn't work," and catching it yourself before sending saves an extra round-trip of confusion.

Choosing a genuinely strong archive password

Since ZIP's legacy encryption has known weaknesses under determined attack, password strength matters more here than it might for, say, a website login protected by rate-limiting and account lockouts — an offline archive has no such protection, meaning an attacker can attempt as many password guesses as they want with no risk of being locked out. A strong archive password should be at least 12 characters, ideally generated randomly rather than chosen — a password manager's built-in generator works well for this, since you're not going to need to memorize it if you're using a Password Vault feature to store and reapply it automatically. Avoid patterns based on personal information (names, birthdates, pet names) that could be guessed through basic research about you, and avoid reusing a password from any other account, since a leaked password from an unrelated breach becomes a working key to this archive too if reused.

A quick checklist before you send a password-protected archive

• Use a password you haven't reused elsewhere — don't expose a password you use on real financial or email accounts.
• Send the password through a different channel than the file itself (e.g. a text message, if the archive went by email) — this defeats anyone who intercepts just one of the two channels.
• For highly sensitive files, prefer 7Z with AES-256 over standard ZIP encryption.
• Don't rely on archive passwords as your only security layer for extremely sensitive data — consider full-disk encryption or a dedicated encrypted container for anything truly critical.

Password-protecting a folder versus individual files

A common point of confusion: should you compress and password-protect an entire folder as one archive, or protect individual files separately? For most purposes, one password-protected archive containing everything is simpler — a single password, a single file to send, and the recipient extracts everything at once. The exception is when different files inside the same folder need different access levels for different people — in that case, separate password-protected archives per recipient, each containing only what that person should see, is the correct approach rather than one shared archive with one shared password covering content some recipients shouldn't access.

A realistic scenario: sending tax documents to an accountant

Picture needing to send scanned tax documents, bank statements, and a W-2 to an accountant during filing season — exactly the kind of sensitive, financially-identifying content where basic email attachment security genuinely isn't sufficient on its own. Bundling everything into one password-protected ZIP, then sending the password itself through a separate channel (a text message, rather than the same email thread), meaningfully raises the bar for anyone who might intercept the email alone. This is a realistic, low-effort security practice worth adopting as a default for any similarly sensitive document exchange, not just tax season specifically.

Troubleshooting

• Recipient says the password doesn't work: double-check for trailing spaces or autocorrect changes if you typed the password into Messages or Notes before sending — smart quotes and autocapitalization can silently alter it.
• "Unsupported compression method" error on Windows: usually happens when a ZIP was created with AES-256 encryption and the recipient's extractor doesn't support that mode — fall back to 7Z, which has more consistent encryption support across platforms.

What happens if you compress an already-encrypted file?

If the file you're compressing is already encrypted at the application level — an encrypted PDF, for instance, or a file that's already inside another password-protected archive — wrapping it in a second password-protected ZIP still adds genuine value rather than being redundant. It hides the fact that the file is sensitive at all from anyone browsing a shared folder or inbox (a suspiciously named encrypted PDF sitting loose can itself be a signal worth hiding), and it means an attacker needs to defeat two independent layers of protection rather than one, even if those layers use different mechanisms.

Frequently asked questions

Will a password-protected ZIP work on Windows too? Yes — standard ZIP password protection is cross-platform. The recipient will be prompted for the password regardless of their operating system.

Can someone see the filenames inside a password-protected ZIP without the password? Often yes, for standard ZIP — the file listing itself isn't always encrypted, only the contents. If even the filenames need to stay hidden, 7Z's header encryption option is the better choice (we cover this in a separate guide).

Is it worth password-protecting files I'm storing locally, not just sending? Yes, particularly on a shared family Mac or a laptop that travels with you. A password-protected archive adds a layer of protection beyond your login password alone — useful if someone else gets temporary access to a logged-in session.

Need to do this regularly? Unzipr keeps password-protected ZIP compression completely free, with optional 7Z + AES-256 encryption available when you need stronger protection — plus a Password Vault in PRO that remembers what you set, so a strong random password never becomes a liability the next time you need to open that same archive.