Research/Education/BIP-39 Passphrase Explained: How the "25th Word" Creates a Hidden Wallet (and Why It's Risky)
# Security

BIP-39 Passphrase Explained: How the "25th Word" Creates a Hidden Wallet (and Why It's Risky)

BloFin Academy06/08/2026

A BIP-39 passphrase is an optional user-chosen string added to your 12 or 24-word seed phrase, and once you set one, it generates an entirely separate wallet from the same recovery words: different addresses, different balances, different keys. Sometimes called the "25th word," it's a powerful second layer of security and a frequent cause of permanent crypto loss when users forget it or store it carelessly.


What is the BIP-39 passphrase (also called the "25th word")?

A BIP-39 passphrase is an optional text string you add during wallet setup that gets combined with your seed phrase to derive a completely separate wallet. It is not in the BIP-39 wordlist; you choose any characters, any length, and the wallet has no way to know whether you set one, because every possible passphrase produces a valid (and different) wallet.

The passphrase was formally specified in BIP-39 itself, the proposal by Marek Palatinus, Pavol Rusnák, Aaron Voisine, and Sean Bowe that became the standard for seed-phrase wallets across the industry (source: BIP-39 Specification). The "25th word" nickname is informal. The spec calls it a passphrase, not a word, because it is free-form text (letters, numbers, symbols, spaces, even emoji) rather than one of the 2,048 dictionary entries that make up the seed phrase itself. Users with 12-word seeds sometimes call it the "13th word" for the same reason. Both nicknames stick because users remember "the extra thing after the words," even if the technical detail (it's user-input text, not a wordlist entry) gets lost.

Read more about how the underlying seed phrase works in our BIP-39 seed phrase explainer.


How does a passphrase create a separate hidden wallet?

The seed phrase plus the passphrase pass through a key-stretching function called PBKDF2 with HMAC-SHA512, 2,048 iterations, where the passphrase becomes part of the salt. The output is a 512-bit binary seed, which then derives all your private keys, addresses, and balances. Change the passphrase by even one character, and the entire wallet changes.

This means a single seed phrase can generate effectively unlimited separate wallets. Use no passphrase, and you get the "standard" wallet, the one most users restore by default. Use the passphrase "vault," and you get a different wallet with different addresses. Use "savings," and you get a third wallet. Each is independent. None shares balances or transaction history with the others.

The mechanism is described in plain language in chapter 5 of Mastering Bitcoin by Andreas M. Antonopoulos and David A. Harding (source: Mastering Bitcoin Chapter 5). What makes this design unusual is that there is no error message for a wrong passphrase. Type "Vault" instead of "vault" during restoration, and your wallet doesn't tell you the passphrase is wrong; it just shows you an empty wallet that happens to belong to no one. This is the source of both the feature's power (plausible deniability) and its risk (typo = permanent fund loss).


What are the legitimate use cases for a BIP-39 passphrase?

The four most common legitimate use cases are protecting against a stolen seed phrase, separating funds across multiple wallets from one backup, defending against coercion through a decoy wallet, and structuring inheritance so heirs need both the seed and the passphrase to access funds.

The most cited use case is protection against a compromised seed phrase. If an attacker photographs, finds, or extracts your 24 words but doesn't know your passphrase, they cannot access the hidden wallet that holds your real balance. The seed phrase alone reveals only the standard (empty or decoy) wallet. Trezor's documentation describes this exact threat model: a seed phrase recovered from a backup paper, a phishing victim's screenshot, or a malware-extracted import file (source: Trezor Guide — Passphrase).

A second use case is operational separation. One physical backup, three passphrases, three wallets: one for daily spending, one for medium-term holdings, one for long-term cold storage. Many users with substantial balances find this easier to track than juggling three separate seed-phrase backups.

A third use case is coercion defense, sometimes called the "$5 wrench attack" scenario. Under duress, you reveal the seed phrase and the no-passphrase wallet, which contains a modest decoy balance. The hidden wallet stays hidden. This works only if the attacker doesn't know hidden wallets are possible, or doesn't have time to test passphrases against your seed.

A fourth, increasingly discussed use case is inheritance. A passphrase stored separately from the seed phrase, in a different jurisdiction, a different format, or a different family member's hands, means no single point of failure can access the funds. Heirs need both. This pattern requires careful planning, especially around what happens if the passphrase holder dies without communicating it.


What are the risks of using a BIP-39 passphrase?

The single biggest risk of a BIP-39 passphrase is permanent fund loss, because there is no recovery path when you forget it, mistype it, or store it where it can't be retrieved. Five specific failure modes account for most reported losses: forgetting, silent typos, Unicode normalization mismatches, mobile keyboard auto-correction, and storing the passphrase on the same paper as the seed.

Forgetting is the most common failure. A user sets a clever passphrase during initial wallet setup, doesn't access the hidden wallet for six months, and finds when they try that the exact phrase is no longer in memory. There is no support line, no password reset, no recovery process. The funds in that wallet are effectively burned.

Silent typos are the second pattern, and they are particularly cruel. Because there is no wrong-passphrase error message, a user who types "MyVault" instead of "myvault" sees an empty wallet and assumes the funds are gone or that the device is broken. Several Trezor forum threads document users who spent days troubleshooting hardware before realizing they had simply mistyped a single character.

Unicode normalization is a less-discussed but real risk. The BIP-39 spec mandates NFKD Unicode normalization on the passphrase, but not every wallet tool enforces this consistently. If you store your passphrase in a password manager that uses a different normalization, the characters that look identical to you may produce a different binary seed when you try to restore in a different application. The safest approach is to use plain ASCII characters: letters a-z, A-Z, digits 0-9, and basic punctuation.

Mobile keyboard auto-correction is responsible for an underappreciated share of losses. iOS and Android keyboards routinely substitute smart quotes for straight quotes, add spaces after periods, capitalize the first letter of an entry, or rewrite words via predictive text. A user who copies a passphrase from a password manager to a mobile wallet often does not realize the keyboard altered the string before the wallet processed it. Disabling auto-correct on the specific field, or pasting rather than typing, mitigates this; but the user has to know to do it.

Finally, co-located storage defeats the entire mechanism. A passphrase written on the same metal plate or paper as the seed phrase offers no additional security: anyone who finds the backup finds both. This is the operational failure that makes the entire feature counterproductive when implemented carelessly.

From Blofin's customer-support inbox, the single most common BIP-39 passphrase failure isn't a hacker; it's the user. Two patterns recur: a passphrase typed once into a Trezor or Ledger during setup and then forgotten within weeks, and a passphrase stored on the same paper as the seed phrase, which defeats the entire point because anyone finding the paper accesses the hidden wallet. Both result in funds permanently inaccessible. The passphrase is a powerful security tool, but only when the user has a real plan for remembering it that doesn't co-locate it with the seed.

Avoid these patterns by reading our guide on common crypto security mistakes and our wallet recovery process reference.


How do major hardware wallets implement passphrases?

Every major hardware wallet supports BIP-39 passphrases, but they differ in where you type the passphrase, whether the device stores it, and how they handle multiple passphrases. The table below summarizes the most popular implementations in 2026.

Wallet

How you enter the passphrase

Storage

Notable quirk

Trezor Model T

On-device touchscreen, or via host computer with on-device confirmation

Not stored on the device; entered fresh every session

NFKD normalization enforced by the device firmware

Trezor Model One

Host (Trezor Suite); on-device step is feature-enable only, characters typed in Suite

Not stored

Older model; passphrase entry is host-side because the device lacks a touchscreen

Ledger Nano S Plus / Nano X

Host application (Ledger Live), with on-device confirmation

"Temporary passphrase" is session-only; "Set passphrase" is tied to a secondary PIN

Two distinct modes; choose carefully (source: Ledger Support — Passphrase)

Coldcard Mk4 / Q

On-device keypad; fully air-gapped entry possible

Optional "Seed Vault" stores up to 100 indexed secrets, including passphrase-derived XPRVs (shared with other secret types)

Most paranoid implementation; designed for never typing the passphrase on a connected computer (source: Coldcard Docs — Passphrase)

Sparrow Wallet (paired with hardware)

Sparrow prompts during PSBT signing

Not stored

Useful for software-coordinator workflows with air-gapped signers (source: Sparrow Wallet FAQ)

Bitcoin Core

Different concept entirely; Bitcoin Core's -walletpassphrase flag encrypts the wallet file at rest, not a BIP-39 derivation passphrase

Wallet-file encryption

Common source of user confusion; these are two separate features with the same word

The Bitcoin Core distinction matters. New users often read "Bitcoin Core supports wallet passphrases" and assume that's the BIP-39 25th word. It isn't. Bitcoin Core's passphrase encrypts the local wallet.dat file; a BIP-39 passphrase is part of the seed derivation chain. They serve different purposes and aren't interchangeable.

For more on the hardware side, see our hardware wallets explainer and our set up a hardware wallet walkthrough.


How should you back up a BIP-39 passphrase safely?

The single rule that makes BIP-39 passphrases safe is to store them separately from the seed phrase, in at least two physical locations, using methods that don't share a single point of failure. Memorization works for some users, but adds the risk that a head injury, cognitive decline, or simply time can erase the passphrase. Most experienced users combine memorization with physical backup, stored apart from the seed.

A practical backup pattern looks like this. The seed phrase lives on a metal plate in a home safe; see our metal seed backup guide for the durability comparison. The passphrase lives on a separate piece of paper or metal in a safe deposit box at a different address. Neither location alone gives an attacker access to the hidden wallet. An attacker who burglarizes the home gets only the seed, which derives the no-passphrase wallet. An attacker who somehow accesses the safe deposit box gets only the passphrase, which is meaningless without the seed.

For inheritance scenarios, the passphrase can sit with a trusted family member or in a lawyer's escrow, with the seed in the home safe. Heirs combining both regain access; either alone does not. Our back up your seed phrase reference covers the broader principles.

Some users store the passphrase in an encrypted password manager (Bitwarden, KeePassXC, 1Password). This is acceptable if the password manager itself has a strong, separately stored master password and is not used to also store the seed phrase. The risk is creating a single digital point of failure: an attacker who compromises the password manager and somehow obtains the seed phrase has both elements.


Common mistakes that lose passphrase-protected wallets

The most common passphrase losses come from a small list of recurring user errors: typos at restoration, keyboard layout mismatches, mobile auto-correct silently rewriting input, smart-quote substitution, locale-character normalization differences, and confusion between a hardware wallet's PIN, the seed phrase, and the passphrase.

Typos at restoration sound trivial but cause real losses. A passphrase set as "MyVault2024" needs to be restored as exactly "MyVault2024." A capital M instead of lowercase, an extra space at the end, or "Vault" with a smart quote where the original used a straight quote: any one produces a different wallet, with no error message.

Keyboard layouts trip up users who set a passphrase on one device and restore on another. A passphrase containing characters that require different key combinations on a US versus UK keyboard, or characters that don't exist on a hardware-wallet keyboard, can fail to restore even when the user types what they remember.

Mobile auto-correct is a silent loss vector. Phone keyboards capitalize the first letter of a sentence, substitute smart quotes for straight quotes, add periods or spaces, and apply predictive text. Many wallet apps disable auto-correct on the passphrase field, but not all do. A user copying a passphrase from a password manager to a mobile wallet may find the keyboard altered the string before the wallet processed it.

Vendor-specific gotchas matter too. Ledger's "Temporary" passphrase is erased on the next device wipe; users sometimes assume it's stored and lose access after a device reset. Coldcard's passphrase Vault stores passphrases by index; a user who forgets which Vault slot holds the active passphrase can spend hours searching. Trezor's NFKD normalization is enforced by firmware, so a passphrase set in newer firmware may not restore on a different vendor's device that handles Unicode differently.

The mitigation across all these patterns is simple: use plain ASCII characters, write the passphrase down exactly as typed (not as you intended), test the restoration immediately by sending a small amount to the hidden wallet and recovering it, and store the verified passphrase in at least two physical locations apart from the seed.


Frequently asked questions

Is the BIP-39 passphrase the same as my seed phrase password protection?

No, they are different mechanisms despite overlapping vocabulary. Some wallets offer "password protection" that encrypts the local wallet file on your device; that is wallet-file encryption, separate from BIP-39 derivation. The BIP-39 passphrase becomes part of the cryptographic derivation that produces your private keys. Wallet-file encryption protects the file on a single device; the BIP-39 passphrase protects the entire hidden wallet across every device that could restore it.

Can I add a passphrase later, after I've already set up my wallet?

Yes, but adding a passphrase creates a brand new wallet: the empty hidden wallet that the passphrase derives, separate from your existing no-passphrase wallet. The previous wallet still exists at the no-passphrase address and still holds whatever balance was there. To move funds into the passphrase-protected wallet, you must send a transaction from the no-passphrase wallet to an address inside the passphrase-protected one. Test with a small amount first.

What happens if I forget my BIP-39 passphrase, can anyone help me recover it?

No. There is no recovery service, no password reset, and no support process for a forgotten BIP-39 passphrase. The passphrase is not stored on the device, not held by the wallet vendor, and not recoverable from the blockchain. If you forget it, the funds in the hidden wallet are permanently inaccessible. This is the central tradeoff of the feature: the same property that makes it secure (no centralized recovery) is what makes forgetting it catastrophic.

Is using a passphrase safer than just using a longer seed phrase?

It depends on what you are defending against. A longer seed phrase (24 words versus 12) gives you more entropy against brute force, a theoretical attack that, with current hardware, is not practical even against 12-word seeds. A passphrase defends against a real-world attack: someone who finds, photographs, or extracts your seed phrase still cannot access the hidden wallet. For most users, the passphrase defends against a far more likely threat (physical compromise of the seed backup) than a longer seed addresses (cryptographic brute force).

Are emoji or non-English characters safe to use in a BIP-39 passphrase?

Technically yes; the BIP-39 spec supports any UTF-8 characters with NFKD normalization. Practically, no. Emoji and non-ASCII characters introduce risk in three ways: different operating systems and keyboards render and input them differently, password managers may apply inconsistent normalization, and the visual identity of similar-looking characters (Cyrillic "а" versus Latin "a") can confuse the user during restoration. Plain ASCII letters, digits, and basic punctuation are the safest choice. Length and unpredictability matter more than character variety.

 


Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include the BIP-39 specification (Palatinus, Rusnák, Voisine, Bowe), Mastering Bitcoin (Antonopoulos & Harding, 3rd edition), Trezor passphrase documentation, Ledger Support, Coldcard documentation, and Sparrow Wallet documentation. All facts independently verified against cited documentation current as of May 2026.

 

This article is for informational purposes only and does not constitute financial advice, investment guidance, or a recommendation to buy, sell, or hold any digital asset. Cryptocurrency markets involve significant risk and you should conduct your own research and consult qualified professionals before making investment decisions. Blofin Academy content reflects the state of public information at time of publication; protocol parameters, fees, and ecosystem data change frequently.