ZipToolView zip files online — 100% private

Zip encryption explained

Not all "password-protected" zips are equally protected, and the difference is not advertised on the file. A zip can be encrypted with one of two very different methods: ZipCrypto, the original scheme from the early 1990s, which is weak and breakable; or AES, the modern standard (AES-128/192/256), which is strong. Both ask for a password. Only one actually keeps a determined attacker out.

This page explains how each works, why an encrypted zip sometimes refuses to open in Windows Explorer or macOS Archive Utility (almost always an AES-vs-ZipCrypto mismatch), and how to choose the secure option. To actually add a password to an archive, see how to password-protect a zip file; to open one privately, see why client-side is safer than uploading.

What encryption in a zip actually does

A zip file is a container: it stores entries (files and folders), and for each entry it can optionally store the entry's data encrypted rather than in the clear. Encryption is applied per entry, so the same archive can mix encrypted and unencrypted files. The password you supply is not used directly — it is stretched into a cryptographic key that decrypts the payload.

Crucially, zip encryption encrypts contents, not always names. With the common ZipCrypto and WinZip AES methods, the list of entry names and their sizes is still visible without the password; only each entry's bytes are hidden. So an encrypted zip can reveal its file tree while keeping the contents secret. Some tools support "header encryption" (encrypting the file index too) so even the names are hidden until the password is supplied — RAR and 7z commonly offer this; plain zip historically does not.

  • Encryption is applied per entry, at the byte level — the password derives a key that decrypts the payload.
  • With ZipCrypto and WinZip AES, entry names and sizes stay visible; only the contents are encrypted.
  • Header encryption (offered by RAR/7z) hides even the names; plain zip usually does not.

ZipCrypto: the weak legacy method

ZipCrypto — also called "traditional" or "classic" PKWARE encryption — is the original scheme, dating to the early 1990s. It is fast and universally compatible, which is why it is still the default in many tools. It is also cryptographically weak. Its 96-bit internal state and short keystream have known weaknesses, and it is vulnerable to known-plaintext attacks: given a copy of one of the unencrypted files inside the archive (a common scenario when a file is partly predictable, like a known readme or license file), an attacker can often recover the password.

A second, more embarrassing flaw is that ZipCrypto has no integrity check of its own, so corrupted bytes can go undetected and the format has historically been prone to implementations that leak information. The practical verdict is consistent across the security community: ZipCrypto is fine for casual deterrence, inadequate against a determined attacker, and not something to rely on for genuinely sensitive data.

  • Fast and universally compatible — still the default in many tools.
  • Weak internal state and vulnerable to known-plaintext attacks.
  • Acceptable for casual deterrence, not for genuinely sensitive data.

AES: the modern, strong method

The strong alternative is AES encryption, introduced by WinZip around 2003 and now widely supported. It uses the AES block cipher (in 128-, 192-, or 256-bit key strengths, AES-256 being the strongest) in CTR mode, derives the key from your password using PBKDF2 with HMAC-SHA1, and authenticates the data with a separate HMAC so tampering is detected. This is real, modern cryptography — the same AES family that protects traffic and storage across the industry.

Because the key is derived from your password with a slow key-stretching function, guessing a weak password is still the main attack: AES does not save you from "password123". But unlike ZipCrypto, a strong password behind AES-256 is not realistically crackable. The strength comes from both the cipher and a password that resists guessing.

  • Uses AES-128/192/256 in CTR mode — modern, strong cryptography.
  • Derives the key with PBKDF2 and authenticates data with HMAC-SHA1, so tampering is detected.
  • Strength depends on the password too — AES does not rescue a weak one.

Why some encrypted zips refuse to open

The most common reason an encrypted zip fails to open is a compatibility mismatch, not a wrong password. The built-in extractors in Windows (File Explorer) and macOS (Archive Utility) only understand the old ZipCrypto method. Hand them an AES-encrypted zip and they either reject it outright or endlessly tell you the password is wrong — even though the password is correct. This trips up nearly everyone the first time they receive a 7-Zip or WinRAR AES-encrypted zip.

The fix is to use a tool that supports AES: 7-Zip, WinRAR, WinZip, Keka (macOS), or an in-browser viewer that decrypts with the right library. If a mainstream tool keeps rejecting a password you are sure is right, the archive is almost certainly AES-encrypted and the OS built-in simply cannot read it. (One honest caveat: if you genuinely do not have the password, no honest tool can bypass encryption — that is the point of it.)

  • Windows File Explorer and macOS Archive Utility only support ZipCrypto, not AES.
  • An AES zip there is rejected or endlessly reported as wrong-password, even with the right password.
  • Open AES zips in 7-Zip, WinRAR, WinZip, Keka, or a capable in-browser viewer.
  • Without the password, no honest tool can decrypt the archive.

Which should you use?

For protecting anything you actually care about, use AES (AES-256 if offered), and pair it with a strong, unique passphrase. Choose the tool deliberately: 7-Zip and WinRAR default to or offer AES; older or simpler tools may fall back to ZipCrypto. If a tool offers "ZipCrypto" or "legacy" versus "AES," always pick AES. ZipCrypto should be reserved for cases where compatibility with ancient software matters more than security — which is rare.

Whatever method you choose, keep the password somewhere safe. Encryption is a one-way door: with a strong cipher and a forgotten password, the data is effectively gone, and no legitimate tool can recover it for you. For step-by-step instructions on adding a password, see how to password-protect a zip file.

  • Use AES (AES-256 if offered) with a strong, unique passphrase for anything sensitive.
  • Pick 7-Zip, WinRAR, or WinZip, which offer AES; avoid tools that default to ZipCrypto.
  • Keep the password safe — a strong cipher plus a forgotten password means the data is gone.

Opening encrypted archives privately

When the archive is sensitive, the tool you decrypt it with matters as much as the encryption. An upload-based site would send the whole encrypted file — and your password, if you enter it there — to a server. A client-side tool decrypts in your browser: the file and the password stay on your device, in memory, and are never transmitted. ZipTool decrypts password-protected zips this way; the password lives only in the tab's memory and is never sent anywhere.

You can confirm a no-upload claim the usual way: open DevTools (F12), watch the Network tab while you supply the password and open entries, and confirm no request carries the file or the password. The broader privacy picture is in security and privacy.

  • A client-side tool decrypts in your browser; the file and password never leave your device.
  • ZipTool keeps the password only in the tab's memory and never transmits it.
  • Confirm no-upload with DevTools while supplying the password and opening entries.

Frequently asked questions

What is the difference between ZipCrypto and AES in zip files?

ZipCrypto is the original, fast, universally compatible encryption from the early 1990s, and it is weak — vulnerable to known-plaintext attacks. AES (AES-128/192/256) is the modern method introduced by WinZip, using real cryptography (AES in CTR mode with PBKDF2 key derivation and HMAC authentication). Both ask for a password, but only AES is strong enough to trust with sensitive data. Use AES; avoid ZipCrypto for anything important.

Why does my encrypted zip say the password is wrong when it is not?

Almost always because the zip uses AES encryption and the tool opening it only supports ZipCrypto. The built-in extractors in Windows (File Explorer) and macOS (Archive Utility) only understand ZipCrypto, so an AES-encrypted zip made by 7-Zip or WinRAR is rejected or endlessly reported as wrong-password there. Open it in a tool that supports AES — 7-Zip, WinRAR, WinZip, Keka, or a capable in-browser viewer — and the same password will work.

Can the entry names in an encrypted zip be seen without the password?

Usually yes. With the common ZipCrypto and WinZip AES methods, the file tree — entry names and sizes — is visible without the password; only each entry's contents are encrypted. If you need the names hidden too, use header encryption, which RAR and 7z commonly offer (plain zip historically does not). Header encryption requires the password before even the file list is shown.

Is AES-256 zip encryption secure?

Yes, when paired with a strong password. AES itself is modern, well-studied cryptography, and AES-256 in a WinZip-style zip uses PBKDF2 key derivation and HMAC authentication. Its only real weakness is the password: a weak passphrase can be guessed regardless of the cipher. Use a strong, unique passphrase and AES-256 is not realistically crackable.

Can I recover a zip if I forgot the password?

Generally no. With a strong cipher (AES) and a strong password, there is no shortcut — an honest tool cannot bypass the encryption, because defeating it would mean the encryption was worthless. Recovery tools exist only for weak ZipCrypto or weak passwords, where they effectively guess. Keep passwords somewhere safe; encryption is a one-way door.

Can I open a password-protected zip without uploading it?

Yes. A client-side tool decrypts the archive in your browser using the library code it already downloaded, so the file and the password stay on your device and are never sent to a server. Confirm it with DevTools (F12, Network tab) while you supply the password and open entries — no request carrying the file or password should fire.