BIP-39 Mnemonic Tool

Is it safe to generate a real wallet's seed phrase with this tool?

No, and this isn't a formality — it's the single most important thing on this page. A seed phrase generated in any browser tab exists, even briefly, in that tab's memory, is potentially visible to a malicious browser extension, and could be captured by clipboard-monitoring malware the moment you copy it. A real wallet's seed phrase should be generated on the hardware wallet itself, or on an air-gapped device that has never touched the internet — never on a general-purpose computer with a browser open to dozens of other sites. This tool exists so you can understand how BIP-39 works — see a real checksum fail, watch entropy turn into words — not to produce a phrase you then send funds to. Treat everything generated here as already compromised the moment it appears on screen.

Why English only — don't other languages have BIP-39 wordlists?

They do — the BIP-39 spec defines wordlists for Chinese (Simplified and Traditional), Czech, French, Italian, Japanese, Korean, Portuguese, and Spanish, in addition to English, each with its own 2048-word list and its own care needed around Unicode normalization (Japanese mnemonics, for instance, join words with an ideographic space, not a regular one, which trips up implementations that don't handle it explicitly). This tool implements only the English wordlist for now — supporting the others correctly means testing normalization edge cases for every script, which is real work this build didn't do yet. If you have a phrase in another wordlist, this tool's checksum validation and entropy conversion will not recognize it as valid, even if it's completely correct in its own wordlist.

What actually makes a 12-word phrase different from a 24-word one?

Word count is a direct, fixed function of how many bits of entropy went in: BIP-39 appends a checksum equal to entropy_bits / 32 onto the entropy before splitting it into 11-bit chunks, one chunk per word. 128 bits of entropy (16 bytes) plus its 4-bit checksum gives 132 bits, which is exactly 12 words of 11 bits each — and 256 bits of entropy (32 bytes) plus its 8-bit checksum gives 264 bits, exactly 24 words. There's no 13-word or 20-word option because those bit counts don't divide evenly by 11 with a valid checksum ratio; only 12, 15, 18, 21, and 24 words correspond to valid entropy sizes (128, 160, 192, 224, 256 bits). More words means more entropy means a larger keyspace an attacker would have to search — 24 words is meaningfully more resistant to brute force than 12, though 12 words (128 bits) is already far beyond what's practically searchable.

Why does checking a phrase say "invalid" even though every word is a real BIP-39 word?

Every real word being in the list is necessary but not sufficient — the last word (or the last few bits of it, depending on word count) encodes a checksum computed from a SHA-256 hash of the preceding entropy, and that checksum has to match exactly. This is deliberate: it catches the single most common real-world mistake, which is a typo or a misheard word when a phrase is copied by hand or read aloud. Swap any word for another valid BIP-39 word, or transpose two words, and the checksum almost certainly breaks — that's the entire point of including one. If your phrase fails validation here, the fix is not to guess-and-check nearby words; go back to wherever the phrase was written down and confirm you transcribed the words and their exact order correctly, ideally reading each one back from the numbered wordlist rather than from memory.

What is the "seed" this tool derives, and how is it different from the mnemonic itself?

The mnemonic (the words themselves) is a human-friendly encoding of raw entropy, nothing more — it's designed to be easy to write down and read back correctly. The seed is a completely different 64-byte value produced by running the mnemonic (plus an optional passphrase) through PBKDF2 with 2048 rounds of HMAC-SHA512, and it's the seed — not the words — that actually feeds into BIP-32 to derive a hierarchical tree of private keys for every address a wallet manages. This two-step design exists partly so wallets can support an optional passphrase (BIP-39 calls it the "25th word"): the same 12 or 24 words with a different passphrase produce a completely different seed and therefore a completely different set of wallet addresses, which is both a useful hidden-wallet feature and a common source of "my funds disappeared" support tickets when someone forgets they'd set one.

Can I recover a real wallet if I lost the software but kept the seed phrase?

In principle, yes, and that's the entire reason BIP-39 exists as a cross-wallet standard — a wallet compliant with BIP-39 and the matching BIP-32/BIP-44 derivation path should reconstruct the identical seed and identical addresses from the same words, regardless of which company's software originally generated them. In practice, the derivation path (which BIP-44 "account" and "chain" numbers were used, sometimes non-standard ones for certain coins) also has to match, so recovering into a different wallet application than the one that created the phrase occasionally needs you to specify that path manually. This tool only reaches the "seed" step — turning a phrase into the 64-byte seed value — and stops there; deriving actual keys and addresses from that seed for a specific coin is a separate BIP-32/BIP-44 derivation this tool does not perform.

Does entering an entropy value directly (Entropy → mnemonic) weaken security compared to generating a phrase?

The security depends entirely on where that entropy came from, not on which direction of this tool produced the words. If you type in 00000000000000000000000000000000 by hand to see the well-known "abandon abandon … about" test phrase, that's exactly as predictable as it looks and must never protect anything real — this is precisely why it's the standard example used across BIP-39 documentation and this tool's own tests. If the hex came from a hardware random number generator or another audited secure source, converting it to a mnemonic here doesn't make it weaker; the conversion is a lossless, deterministic encoding. The "Generate" tab is safer for casual use specifically because it removes the human from the entropy-sourcing step entirely, drawing bytes straight from crypto.getRandomValues.