BIP39's Unicode Trap
A BIP39 passphrase can be an emoji.
That is permitted by the standard. It is also a surprisingly dangerous property for something a person may need to reproduce years later, on a different device, with a different keyboard.
The passphrase is often called the “25th word,” although it is neither limited to one word nor part of the mnemonic. BIP39 combines the mnemonic with an optional passphrase to derive the wallet seed. Every passphrase produces a valid seed. There is no checksum for the passphrase and no “incorrect passphrase” result. A typo simply opens a different, usually empty, wallet.
That makes exact text entry part of the key.
What BIP39 specifies
The BIP39 specification is precise about the cryptography. The mnemonic and passphrase are encoded as UTF-8 after NFKD normalization. PBKDF2-HMAC-SHA512 then derives a 512-bit seed using 2,048 iterations.
It does not restrict the passphrase to English, ASCII, words, or any particular length. Empty text is valid. Japanese is valid. Accented text is valid. Emoji are valid. Spaces and invisible Unicode characters are valid.
NFKD normalization is meant to give equivalent Unicode text a common byte representation. For example, é can be represented as one code point or as e followed by a combining accent. After NFKD, those two forms become the same sequence.
That solves a real interoperability problem. It does not solve the whole human-input problem.
The coffee problem
Consider these two passphrases:
coffee ☕
coffee ☕️
Depending on the font and device, they may look identical. Internally, the first coffee symbol can be one Unicode code point. The second can contain that same code point followed by an invisible variation selector requesting emoji presentation.
NFKD does not remove the variation selector. The normalized UTF-8 bytes remain different. The resulting BIP39 seeds—and every address derived from them—are different.
The same class of problem appears elsewhere:
- A straight apostrophe and a smart apostrophe look related but are different characters.
- An ordinary space, a non-breaking space, and several other Unicode spaces may be difficult or impossible to distinguish on a small display.
- Emoji can contain invisible variation selectors, skin-tone modifiers, or zero-width joiners.
- A keyboard may replace punctuation, offer a composed character, or insert text differently from the keyboard used when the passphrase was created.
The Unicode normalization standard is explicit that compatibility normalization must not be applied blindly to arbitrary text. Normalization creates stable forms for defined equivalences; it does not promise that two strings which look alike to a person are the same string.
For ordinary text, that is manageable. For a wallet passphrase, one invisible code point changes every key.
A standards gap, not a cryptographic break
BIP39 is doing what it says. A conforming implementation normalizes both inputs with NFKD and derives the seed deterministically. The cryptography is not ambiguous.
The gap is at the recovery interface. BIP39 permits a much larger character space than people can reliably transcribe, inspect, and reproduce across modern text systems. It defines how software turns Unicode into a seed, but not a portable input profile for humans.
That omission is serious because failure is silent. If a recovery PIN is wrong, encrypted backup software can reject it. If a BIP39 passphrase is wrong, the derived wallet is still perfectly valid. It just is not your wallet.
A user can therefore enter what appears to be the same passphrase, see an empty balance, and have no machine-readable way to tell whether the problem is a hidden character, a different punctuation mark, the wrong account path, or genuinely the wrong wallet.
There is no standard maximum length either. Wallets must choose their own practical UI limits, and two otherwise conforming wallets may accept different amounts of text.
Cryptograph’s deliberately smaller profile
Cryptograph currently accepts BIP39 passphrases only through its advanced 24-word recovery flow. It restricts the passphrase to printable ASCII, caps it at 50 characters, and rejects leading, trailing, or repeated spaces.
Those restrictions are stricter than BIP39. They are intentional.
ASCII is unchanged by every Unicode normalization form, including NFKD. A straight apostrophe remains a straight apostrophe. A normal space remains one visible byte. Emoji, smart quotes, accented characters, non-breaking spaces, combining marks, variation selectors, and zero-width joiners cannot enter the passphrase at all.
The 50-character limit is not a BIP39 rule. It is a product limit chosen so the passphrase can be entered and reviewed on a watch. The spacing rules address the same recovery concern: whitespace that is easy to add accidentally is too consequential to accept silently.
This is a tradeoff. A user in a non-English locale cannot create a passphrase in their native script. Someone importing an existing Unicode passphrase cannot use Cryptograph’s BIP39 recovery flow today. If real users need that interoperability, it deserves a carefully designed mode with exact cross-platform test vectors and a display that exposes ambiguous characters—not a text field that accepts everything because the standard allows it.
For now, Cryptograph chooses the smaller interoperable surface. Any standards-compliant BIP39 wallet can derive an ASCII passphrase correctly, and ASCII avoids the normalization and rendering ambiguities that make arbitrary Unicode fragile as a recovery secret.
The practical rule
If you use a BIP39 passphrase in any wallet, treat it as cryptographic data rather than prose.
Record its exact spelling, capitalization, punctuation, and spaces. Do not assume two strings are equal because they look equal. Confirm recovery before funding the wallet. Remember that the mnemonic alone is not sufficient: without the exact passphrase, there is no reset, warning, or recovery path.
“Any Unicode string” is elegant in a specification. A recovery system has a harsher requirement: the same human must be able to produce the same bytes years later.
Cryptograph is available now on the App Store.
The Cryptograph Team