Introduction
Need to validate a Bitcoin address, generate a BIP39 mnemonic phrase, or verify a Merkle proof? Blockchain tools handle the cryptographic primitives that underpin Bitcoin, Ethereum, and other cryptocurrency systems. These are not trading tools. They are encoding and verification utilities that operate on addresses, keys, and proofs. Every tool runs in your browser. No private keys or seed phrases are transmitted.
What this category includes
- Address validators and decoders for Bitcoin (legacy, SegWit, native SegWit) and Ethereum (with EIP-55 checksum)
- BIP39 mnemonic phrase generator using the standard 2048-word English wordlist
- Base58Check encoder and decoder (the encoding used for Bitcoin legacy addresses)
- Bitcoin address generator showing the full key-pair-to-address pipeline
- Merkle tree builder and Merkle proof verifier for verifying data inclusion
How these tools work
Bitcoin and Ethereum addresses are not random strings. They are the output of a specific cryptographic pipeline, and each format has its own checksum rules.
A Bitcoin legacy address (starting with 1) is generated as follows: start with a private key, derive the public key using ECDSA over secp256k1, hash it with SHA-256, hash the result with RIPEMD-160, prepend a version byte, append a Base58Check checksum (the first 4 bytes of double-SHA-256 of the versioned payload), and encode the whole thing in Base58. SegWit addresses (starting with 3) and native SegWit addresses (starting with bc1) use Bech32 encoding instead of Base58Check, as specified in BIP173.
Ethereum addresses are the last 20 bytes of the Keccak-256 hash of the public key. EIP-55 introduces a mixed-case checksum where the case of each letter is determined by the corresponding hex digit of the hash of the lowercase address. The Ethereum checksum validator confirms this casing.
BIP39 mnemonic generation, as specified in BIP 39, works like this: generate 128 to 256 bits of entropy, append the first ENT/32 bits of its SHA-256 hash as a checksum, split the result into 11-bit groups, and map each group to a word in the 2048-word English wordlist. This produces 12 words for 128-bit entropy or 24 words for 256-bit entropy. The mnemonic is then converted to a 512-bit seed using PBKDF2-HMAC-SHA512 with 2048 iterations.
Base58Check encoding, defined in the Bitcoin wiki, uses a 58-character alphabet (1-9, A-Z excluding I and O, a-z excluding l) to avoid characters that look similar. The 4-byte checksum is the first 4 bytes of SHA-256(SHA-256(payload)).
All operations run client-side using JavaScript implementations of SHA-256, RIPEMD-160, Keccak-256, and Base58.
How the underlying systems work
BIP39 was authored by Marek Palatinus, Pavol Rusnak, Aaron Voisine, and Sean Bowe. It is the standard for human-readable seed backups across nearly all hardware and software wallets, including Ledger, Trezor, Coldcard, and Electrum. A 24-word mnemonic has 2^256 possible combinations, which is roughly the same number as atoms in the observable universe. The last word in a BIP39 mnemonic is not fully random: it encodes 3 random bits and 8 checksum bits derived from the SHA-256 hash of the entropy. This is why changing a single word in a valid mnemonic almost always produces an invalid one.
Base58Check was chosen by Satoshi Nakamoto for Bitcoin addresses to reduce transcription errors. It removes zero (0), capital O, capital I, and lowercase l from the Base64 alphabet because these characters are easily confused. The 4-byte checksum means a single mistyped character is detected with probability 1 - 2^-32, which is over 99.9999999%.
Ethereum's EIP-55 checksum, proposed by Vitalik Buterin in 2016, is a case-based checksum rather than a separate checksum field. The address itself is unchanged in lowercase. The casing of each hex letter is determined by the corresponding nibble of the Keccak-256 hash of the lowercase address. If the hash nibble is 8 or higher, the letter is uppercase. Otherwise it is lowercase. This means an address with no letters (all digits) has no checksum, but such addresses are rare.
Merkle trees, named after Ralph Merkle who published the concept in 1979, are the data structure Bitcoin uses to summarize all transactions in a block. Each leaf is the hash of a transaction. Each internal node is the hash of its two children. The root hash appears in the block header. A Merkle proof is the set of sibling hashes needed to verify that a specific transaction is included in a block without downloading all transactions.
How to use these tools
- Select the tool you need (Bitcoin address validator, BIP39 generator, Base58Check, Merkle proof, etc.)
- For validators, paste the address or mnemonic you want to check
- For generators, choose the entropy size (128, 256 bits) or address format (legacy, SegWit, native SegWit)
- The tool displays the validation result, decoded components, or generated output instantly
- For Merkle tools, paste the leaf data and the proof hashes to verify inclusion
Real-world examples
Validating a Bitcoin Bech32 Address
A merchant receives a payment to "bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq". They paste it into the Bitcoin address validator, which confirms it is a valid native SegWit (Bech32) address, decodes the 20-byte witness program, and shows the version byte (0 for SegWit). The tool also confirms the Bech32 checksum is valid, meaning no characters were mistyped.
Generating a Test BIP39 Mnemonic
A developer building a wallet integration needs a test mnemonic that is not tied to real funds. They open the BIP39 generator, select 128-bit entropy, and get a 12-word phrase like "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about". They verify the checksum is valid and use the phrase in their test environment. They never use this phrase on mainnet because it is a well-known test vector.
Verifying an Ethereum EIP-55 Checksum
A user receives the Ethereum address "0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed" and wants to confirm it was not mistyped. They paste it into the Ethereum checksum validator, which confirms the casing matches the EIP-55 checksum derived from the Keccak-256 hash of the lowercase address. The tool also shows what the address would look like with an incorrect checksum, so the user can spot the difference.
Comparison of methods
| Method | Complexity | Typical use |
|---|---|---|
| Base58Check (legacy) | O(n) encoding | Bitcoin legacy addresses (1-prefix) |
| Bech32 (SegWit) | O(n) encoding | Bitcoin native SegWit (bc1-prefix) |
| EIP-55 (Ethereum) | O(n) hashing | Ethereum address checksum |
| BIP39 (12-word) | O(1) generation | 128-bit entropy backup |
| BIP39 (24-word) | O(1) generation | 256-bit entropy backup |
| Merkle proof | O(log n) verification | Transaction inclusion verification |
Limitations
These tools are for validation, education, and testing. Never paste a real seed phrase or private key into any web tool, including this one. Even client-side tools can be compromised by a malicious browser extension or a supply-chain attack on a dependency. If you need to verify a seed phrase, do it offline on a hardware wallet. The BIP39 generator on this site uses cryptographically random values from crypto.getRandomValues(), but you should still treat any generated phrase as potentially observed. Never send cryptocurrency to an address generated by a web tool for real storage.
Frequently asked questions
What is a BIP39 seed phrase and how does it work?
BIP39 is a standard for generating human-readable mnemonic phrases that back up cryptocurrency wallets. It takes 128 to 256 bits of random entropy, appends a checksum (the first ENT/32 bits of the SHA-256 hash), splits the result into 11-bit groups, and maps each group to a word in a 2048-word English wordlist. A 128-bit entropy produces 12 words. A 256-bit entropy produces 24 words. The mnemonic is then converted to a 512-bit seed using PBKDF2-HMAC-SHA512 with 2048 iterations.
Why does the last word of my BIP39 mnemonic look like it could be any word?
The last word of a BIP39 mnemonic is not fully random. It encodes 3 random bits (for 24-word phrases) or 7 random bits (for 12-word phrases) plus 8 checksum bits derived from the SHA-256 hash of the entropy. This means only about 1 in 256 words from the wordlist will produce a valid checksum for a given set of preceding words. If you change one earlier word, the last word almost always becomes invalid.
What is the difference between a Bitcoin legacy address and a SegWit address?
Legacy addresses (starting with 1) use Base58Check encoding and P2PKH scripts. SegWit-in-P2SH addresses (starting with 3) wrap SegWit transactions in a P2SH script. Native SegWit addresses (starting with bc1) use Bech32 encoding as specified in BIP173 and are the current standard. Native SegWit has lower fees and better malleability properties than the older formats.
What is EIP-55 and why do Ethereum addresses have mixed case?
EIP-55 is a checksum standard for Ethereum addresses proposed by Vitalik Buterin in 2016. The case of each hex letter in the address is determined by the corresponding nibble of the Keccak-256 hash of the lowercase address. If the nibble is 8 or higher, the letter is uppercase. Otherwise it is lowercase. This lets wallets detect mistyped addresses without adding a separate checksum field.
Is it safe to paste my real seed phrase into this tool?
No. Never paste a real seed phrase into any web tool. Even though this tool runs client-side, a compromised browser extension or a supply-chain attack on a dependency could intercept the phrase. If you need to verify a seed phrase, do it offline on a hardware wallet. Use this tool only with test mnemonics or entropy you generated for testing.
Related categories
Conclusion
Blockchain tools handle the cryptographic encoding and verification primitives behind Bitcoin and Ethereum: address validation, BIP39 mnemonic generation, Base58Check encoding, and Merkle proofs. Use them to learn how addresses are constructed, validate a checksum before sending funds, or verify a transaction inclusion proof. For the underlying encryption algorithms, see Modern Cryptography. For hashing, see Security & Hashing.