Blockchain.com backup file won't decrypt? wallet.aes.json, 'decrypt failed', and legacy phrase fixes

If you have an old Blockchain.info or Blockchain.com wallet backup and it "won't decrypt," "decrypt failed," or "won't open," the coins are usually not gone. A decrypt error almost always means a fixable mismatch between the file you have, the password you're typing, and the tool you're using, not that the wallet is destroyed. This is a triage guide for that exact moment.

Two safety rules before anything else. Do not paste your backup or your password into a random "wallet decrypt" website, and do not hand either to someone who contacted you first offering to recover it. Uploading an encrypted backup to a stranger's site is how a recoverable wallet becomes a stolen one. If you're vetting who to trust with this, read how to tell a legitimate recovery service from a scam first.

First, identify what you actually have

"My backup won't open" covers several very different situations. Work out which one is yours before trying to fix it:

1. A wallet.aes.json file (or a .json / .txt blob that looks like scrambled text). This is the encrypted wallet backup. It needs your main wallet password to decrypt.
2. A wallet identifier plus a password. The identifier is a GUID that looks like a1b2c3d4-..... On its own it identifies the wallet on Blockchain's servers but does not decrypt anything locally.
3. A 12-word recovery phrase that restores an empty or wrong wallet in another app. That is a different problem, covered further down.
4. Access to the wallet but not the funds. You can log in but cannot spend. That is almost always the second-password (double-encryption) case below.

The recovery path is completely different for each, so naming yours correctly saves days of guessing.

What wallet.aes.json actually is

Blockchain.info and Blockchain.com "My Wallet" web wallets store the wallet as a single AES-encrypted JSON payload, saved to disk as wallet.aes.json. Your password is stretched with PBKDF2-SHA1 and used as the AES key. Nothing inside the file is readable until it decrypts correctly, which is why a wrong password looks identical to a corrupt file: both just produce "decrypt failed."

The format has gone through versions (commonly referred to as v1, v2, and v3). The practical difference is the PBKDF2 iteration count and a few structural details. Modern v2/v3 backups default to 5,000 PBKDF2-SHA1 iterations, which you can see reported by password-recovery tools when they open the file. Older v1 backups used a different, often lower iteration count and a slightly different layout, which matters because a tool that assumes the wrong version will fail to decrypt a perfectly good file. If you know roughly what year the wallet was made, that alone narrows the version.

"Decrypt failed" - the common causes, in order

Most decrypt failures come down to one of these, roughly most-likely first:

• Wrong password, or the right password typed slightly wrong. Old habits (a trailing number, a capital first letter, a date suffix) are usually the culprit. If you remember fragments but not the whole thing, that is a brute-force job, not a dead end - see below.
• A partial or truncated file. When people copy a backup out of an email, a chat, or a browser view, they often grab only part of the JSON. If the file does not start with { and end with }, or is much shorter than a few kilobytes, you have a fragment, not the wallet. Find the original, complete copy.
• It's already decrypted (or double-wrapped). Some exports are plain JSON, not the AES blob. If you can read recognizable text and field names inside the file, it is not encrypted and you should not be running it through a decrypter at all.
• Wrong tool or wrong version assumption. A decoder built for one backup version can choke on another. This is common with the oldest wallets.
• A second password is set. The outer decrypt can succeed while the keys stay locked. That is its own case, next.

The second-password (double-encryption) trap

Blockchain wallets had an optional "second password" that separately encrypts the private keys inside the already-decrypted wallet. This is why some people can log in, see their balance, and still cannot send: the wallet opened, but the keys did not. If your symptom is "I'm in but I can't spend," or a decrypt half-works and the private keys still look like gibberish, you are looking for the second password, not the main one. Treat it as a second, independent password-recovery problem, and write down everything you remember about it separately.

When a legacy phrase restores an empty or wrong wallet

A very common and misread failure: you enter your 12-word phrase into a wallet app and it restores, but the balance is zero or the addresses are unfamiliar. People conclude the coins were stolen or the phrase is fake. Usually neither is true.

• Legacy, non-BIP-39 wallets. The oldest Blockchain.info wallets predate the modern BIP-39 12-word standard. A recovery mechanism from that era will not restore in a standard BIP-39 wallet at all. If a "12-word phrase" does not validate, do not force it into a BIP-39 field - the wallet's actual keys live in the backup file, not the phrase.
• Wrong derivation path or account. Even a valid phrase can restore an empty wallet if the app looks at the wrong derivation path or the wrong account index. Blockchain.com wallets can hold multiple accounts, and the funds may sit on an account or address type (legacy vs SegWit) the restoring app didn't scan. An empty-but-should-be-full restore is a derivation problem until proven otherwise, the same class of issue we document for MultiBit and other bitcoinj-era wallets.
• Imported addresses aren't in the phrase. Any address you imported into the wallet (rather than one it generated from the seed) is not covered by the recovery phrase. Those keys only exist inside the wallet backup.

The takeaway: a phrase that restores nothing is a reason to keep the backup file safe, not to give up.

Preserve everything before you experiment

Whatever you have, protect it before testing passwords or restoring phrases:

1. Make copies of the backup file and store them somewhere you won't overwrite. Never edit the only copy.
2. Don't reinstall or "reset" anything that might still hold a cached copy of the wallet.
3. Write down every password guess and result so you don't repeat work, and so any professional you later trust doesn't start from zero.
4. Record the wallet identifier and any known receiving addresses. Known addresses let a recovered candidate be checked against the right wallet instead of guessed.

When this becomes a recovery case

Some of these you can resolve yourself with the file and patience. The ones worth handing off:

• Forgotten main or second password, with fragments remembered. This is a targeted GPU brute force against the encrypted backup, not blind guessing. The mechanics, and why a good token list matters far more than raw speed, are in how I brute force Blockchain.info wallets. See also forgotten wallet password recovery.
• A file that won't open in any tool. Version mismatches, partial files, and structural damage are exactly the corrupt wallet-file recovery problem.
• A phrase that restores empty or wrong. Derivation-path and legacy-format work; start at seed phrase recovery.

If you'd rather not fight the file yourself, that is the service: Blockchain.com wallet recovery by David Veksler through a Colorado LLC, with published pricing, a free evaluation, and no fee until your crypto is back. Describe what you have, not your secrets, in the first message. Start your free evaluation →