Archive

Fix "CRC failed in the encrypted file. Wrong password?" Error

Error message: CRC failed in the encrypted file. Wrong password?

Fix “CRC failed in the encrypted file. Wrong password?” Error

CRC failed in the encrypted file. Wrong password? is one of the most genuinely ambiguous error messages in archive software. The question mark at the end is intentional — 7-Zip and WinRAR cannot definitively tell you whether the password is wrong or the archive itself is corrupted. Both produce the same observable failure: the decryption runs, but the resulting bytes don’t match their expected CRC checksum. This guide walks through how to distinguish the two cases and what to do for each.

Quick fix

Before doing anything else, rule out the simple causes:

  1. Re-type the password rather than pasting it. Copy-paste frequently captures trailing whitespace, smart quotes, or invisible characters that break decryption. Type the password by hand into the prompt at least once before assuming the password itself is correct.
  2. Test the password on a different file you encrypted with the same password. If you can confirm the same password works for another archive, you’ve ruled out password error as the cause. If you can’t — for example, if this is a one-off archive — set this approach aside and proceed to file-side diagnostics below.
  3. Re-download or re-copy the archive. If the file came from email, a website, or a cloud sync, fetch a fresh copy. Encrypted archive files are particularly sensitive to even single-byte transit damage because the entire structure depends on cryptographic verification.

If the password definitely works for other archives encrypted the same way, and a fresh copy of the archive shows the same error, the file is genuinely damaged.

Distinguishing wrong password from corrupted archive

This is the central diagnostic question. The behavior is informative in subtle ways:

For 7z archives compressed with LZMA2 (the default), a wrong password typically produces Data error in encrypted file. Wrong password? rather than CRC failed. This is because 7-Zip first decrypts, then attempts LZMA2 decompression on the decrypted bytes. Wrong password means wrong decryption means garbage bytes that LZMA2 cannot decode, and the failure surfaces as a data error. If you’re getting CRC failed specifically on an LZMA2-compressed encrypted 7z, that’s actually a stronger signal of file corruption than of password error.

For 7z archives stored without compression (created with -mx0, sometimes used for already-compressed content like JPEGs), wrong password produces CRC failed directly because the CRC is the only verification step. In this case the error genuinely is ambiguous.

For ZIP archives, the behavior depends on the encryption method. Legacy ZipCrypto produces Wrong password cleanly; AES-encrypted ZIP files (the modern method, used by 7-Zip and recent WinRAR) behave more like 7z and produce CRC errors in either failure mode.

For RAR archives with recovery records, you have a meaningful diagnostic available: WinRAR can verify the recovery records independently of the encryption. If the recovery records check out clean and you still get CRC failures during extraction, the password is the more likely cause. If the recovery records themselves report damage, the file is genuinely corrupted.

The most reliable test: encrypt a small, known file with the same password using the same tool, then attempt extraction with the suspect password. If that small archive opens cleanly, your password is correct and the larger archive is the problem.

If the password is confirmed correct

Treat the file as damaged and apply the standard recovery sequence:

For multi-volume archives, verify all parts are present and intact. Encrypted multi-volume archives are particularly vulnerable to missing parts because the decryption is continuous across volumes. Open the first volume only (.zip.001 or .part1.rar), confirm every subsequent part is in the same folder with sequential numbering, and confirm none has been truncated. The 7-Zip recovery page documents techniques for working around a single missing intermediate part by substituting same-size data, though the file in that part will be unrecoverable.

Try a different tool. 7-Zip and WinRAR are not the only options. PeaZip, Bandizip, and the command-line unzip (Info-ZIP) and unrar tools all have different tolerance for partially-damaged encrypted archives. If 7-Zip refuses extraction past a certain point, WinRAR or unrar -kb (keep broken files) might extract more.

If the archive has WinRAR recovery records, run repair. Open the archive in WinRAR, then Tools → Repair archive. If recovery records were included when the archive was created (the -rr switch or Add recovery record option), WinRAR can use them to repair small areas of damage. The repaired output should then accept the password normally. Without recovery records this step has no effect.

Check the source storage if the file came from removable media. USB sticks, particularly old or low-quality ones, develop bit errors that don’t show up until you try to read affected sectors. If the original source archive is on a USB drive, copy it to your hard drive first and try extraction from there. If the copy itself takes longer than expected or shows read errors, the storage is failing and the file you have may be genuinely beyond recovery without a different copy from the source.

If the password is genuinely lost

If you don’t have the password and never did — you’re trying to open an inherited file, an old archive whose password you forgot, or a file you received without the password — that’s a separate problem from this error. Modern AES-encrypted archives (the default for 7-Zip and recent WinRAR/ZIP) use cryptographically strong encryption with key stretching designed specifically to make brute force attacks impractical. For a long random password, recovery is effectively impossible with current technology. For a short or guessable password, dictionary attacks may eventually succeed but are not in scope for this error-specific guide.

The dedicated ZIP password lost guide covers password recovery scenarios honestly, including which encryption methods are weak (legacy ZipCrypto), which are strong (modern AES-256), and what realistic options exist in each case.

Why this error is genuinely ambiguous

Encryption fundamentally changes how archive verification works. With an unencrypted archive, the tool decompresses the data and compares the result against the stored CRC. With an encrypted archive, the tool first decrypts using your supplied password, then either decompresses (if the archive is compressed) or directly verifies the CRC (if it’s not). Wrong password produces wrong decrypted bytes, which fail the CRC check by design. File corruption inside the encrypted blob also produces decrypted bytes that fail the CRC check. From the tool’s perspective, these two failure modes look identical at the point where the CRC mismatch occurs — the tool genuinely cannot tell which happened.

Igor Pavlov, 7-Zip’s author, has confirmed this in 7-Zip discussions: the question mark in the error message is deliberate, reflecting the tool’s inability to distinguish these cases. The order in which 7-Zip tries different failure interpretations affects which exact wording you see, but the fundamental ambiguity is built into the encryption + CRC design itself.

This is one reason careful archive workflows include redundancy beyond just the encryption: external checksums published alongside the archive (typically SHA-256 of the encrypted file), recovery records (in RAR), or PAR2 parity files (Usenet convention) all provide independent verification that doesn’t depend on knowing the password. With any of these, you can verify the file’s integrity before attempting extraction and resolve the ambiguity in advance.

Preventing this in future

For archives you create, prefer formats and options that allow independent verification. RAR’s -rr recovery records are the simplest in-band option — a small size increase in exchange for the ability to verify and repair the file without needing the password. For 7z archives, external PAR2 files give similar protection.

Publish or record SHA-256 hashes alongside important archives. Verifying the encrypted file matches its expected hash before attempting extraction tells you whether the file is intact in seconds, and definitively rules out file-side corruption as the cause of any extraction failures that follow.

When transferring encrypted archives, prefer protocols and tools with end-to-end integrity checking. HTTPS and SCP both detect transit corruption automatically; raw FTP and some legacy email gateways do not. For very large files, tools like rclone and rsync with checksum verification confirm the destination file matches the source exactly.

If extraction fails on a non-encrypted archive with similar CRC errors, see extraction fails partway, which covers data corruption diagnostics for unencrypted files. For RAR-specific CRC failures (encrypted or not), the RAR CRC failed guide goes deeper on RAR’s recovery record system. If the archive won’t open at all rather than failing during extraction, see the archive unknown format or damaged guide. For password recovery scenarios specifically, the ZIP password lost guide provides an honest assessment of what’s recoverable and what isn’t. The archive repair complete guide is the category pillar.

Last verified: April 2026