Introduction
A Bitcoin address is not a random string. It is the end product of a specific chain of cryptographic operations: a random private key, an elliptic curve multiplication on secp256k1, a SHA-256 hash, a RIPEMD-160 hash, and a Base58Check or Bech32 encoding. This tool performs every step in your browser and shows you the intermediate values. You get a fresh key pair on load, with the private key in hex and WIF format, the compressed public key, and three address types (legacy P2PKH, nested SegWit P2SH-P2WPKH, and native SegWit P2WPKH). You can also paste any Bitcoin address to validate its format and detect its type.
What this tool does
- Generate a random 32-byte private key and derive the secp256k1 public key (compressed, 33 bytes) entirely in your browser
- Compute Hash160 (RIPEMD-160 of SHA-256 of the public key) and display it as a 20-byte hex string
- Derive three address types from the same key pair: Legacy P2PKH (Base58Check with prefix 0x00), Nested SegWit P2SH-P2WPKH (Base58Check with prefix 0x05), and Native SegWit P2WPKH (Bech32 with HRP 'bc')
- Export the private key in Wallet Import Format (WIF, Base58Check with prefix 0x80 and compression flag) and raw hex
- Validate pasted Bitcoin addresses by detecting the format (P2PKH, P2SH, P2WPKH, P2TR), network (mainnet, testnet), and reporting whether the checksum is valid
- Run entirely client-side: private keys are generated with crypto.getRandomValues and never transmitted
How this tool works
The tool generates a 32-byte private key using the Web Crypto API's getRandomValues, which provides cryptographically secure randomness. It then computes the public key by performing scalar multiplication on the secp256k1 elliptic curve (y^2 = x^3 + 7 over the prime field p = 2^256 - 2^32 - 977). The public key is compressed to 33 bytes: a prefix byte (0x02 for even y, 0x03 for odd y) followed by the 32-byte x-coordinate.
From the compressed public key, the tool computes Hash160 = RIPEMD-160(SHA-256(publicKey)), producing a 20-byte hash. For the Legacy P2PKH address, it prepends the version byte 0x00 and encodes the result with Base58Check, which appends a 4-byte double-SHA-256 checksum. For the Nested SegWit P2SH-P2WPKH address, it constructs the redeem script (0x00 + 0x14 + Hash160), hashes it with Hash160, prepends 0x05, and Base58Check-encodes. For the Native SegWit P2WPKH address, it uses Bech32 encoding with the human-readable part 'bc' and witness version 0.
The private key is exported in WIF format: Base58Check(0x80 + privateKey + 0x01), where 0x01 signals compressed public keys. The address validator reverses these steps, decoding Base58Check or Bech32, checking the checksum, and identifying the address type from the version byte or witness program structure.
All cryptography runs in your browser. No private key material is sent to any server. The tool displays a warning that these keys are for educational purposes only and should never be used with real funds.
How Bitcoin address derivation works (secp256k1, BIP 32, BIP 173)
Bitcoin's address derivation follows the design described in Section 2 of the Bitcoin Whitepaper by Satoshi Nakamoto (2008) and refined in subsequent BIPs. The elliptic curve secp256k1 is specified in SEC 2 by the Standards for Efficient Cryptography Group. Its parameters are fixed: the generator point G, the prime p, and the order n. The public key is K = k * G, where k is the private key scalar and * is elliptic curve point multiplication.
The Hash160 step combines SHA-256 (specified in FIPS 180-4) and RIPEMD-160. Satoshi chose RIPEMD-160 for its 160-bit output, which keeps addresses short. The double-SHA-256 checksum in Base58Check catches transcription errors. The Base58 alphabet omits 0, O, I, and l to avoid visual ambiguity, as documented on the Bitcoin Wiki.
Hierarchical Deterministic (HD) wallets, specified in BIP 32, derive child keys from a master seed using HMAC-SHA512. This tool generates single keys, not HD chains. For HD wallet derivation, see the Mnemonic Phrase Generator.
Bech32 encoding for SegWit addresses is specified in BIP 173. It uses a 32-character alphabet and a BCH error-detecting code that can detect up to 4 errors with a false-positive rate below 10^-9. The human-readable part 'bc' identifies mainnet. BIP 173 was later extended by BIP 350 for witness version 1 (Taproot) addresses.
How to use this tool
- Click Generate New Key Pair to create a fresh private key and derive all address types. A new key pair is also generated automatically on page load
- Review the Private Key section: WIF format (starts with K or L for compressed mainnet keys) and raw hex (64 characters)
- Review the Public Key section: compressed hex (66 characters, starting with 02 or 03)
- Check the Derived Addresses: Legacy P2PKH (starts with 1), Nested SegWit P2SH-P2WPKH (starts with 3), and Native SegWit P2WPKH (starts with bc1q)
- To validate an existing address, paste it into the input field. The tool detects the type (P2PKH, P2SH, P2WPKH, P2TR), network (mainnet or testnet), and checksum validity
- Read the Derivation Steps panel to see the exact sequence: private key, public key, Hash160, and the encoding for each address type
- Use the Copy buttons to copy any field to your clipboard
Real-world examples
Generating a Legacy P2PKH address
Click Generate. The tool produces a 32-byte private key, computes the compressed public key, hashes it with Hash160, prepends 0x00, and Base58Check-encodes. The resulting Legacy address starts with '1' and is 26 to 34 characters long. This is the original Bitcoin address format from the 2009 release, still supported by all wallets but superseded by SegWit for lower fees.
Comparing P2SH-P2WPKH and P2WPKH addresses
From the same key pair, the Nested SegWit address starts with '3' (Base58Check, P2SH wrapper around a SegWit redeem script) while the Native SegWit address starts with 'bc1q' (Bech32, direct witness program). Both spend from the same public key hash, but Native SegWit has lower transaction weight and fees. Nested SegWit exists for backward compatibility with wallets that cannot send to Bech32 addresses.
Validating a Bech32 address
Paste `bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4` into the input field. The tool decodes the Bech32 string, verifies the checksum, identifies it as P2WPKH on mainnet, and reports the witness version (0). If you change a single character, the checksum fails and the tool reports the address as invalid. This catches typos before funds are sent.
Understanding WIF private key format
The WIF (Wallet Import Format) private key is Base58Check(0x80 + 32-byte-private-key + 0x01). The 0x80 prefix marks it as a mainnet private key. The 0x01 suffix indicates a compressed public key. The resulting string starts with 'K' or 'L' and is 52 characters. Importing this WIF into any wallet reproduces the same compressed public key and all derived addresses.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| Legacy P2PKH | Base58Check, prefix 0x00 | Original format, widely supported, higher fees |
| Nested SegWit P2SH-P2WPKH | Base58Check, prefix 0x05, redeem script wrapper | SegWit benefits with legacy wallet compatibility |
| Native SegWit P2WPKH | Bech32, HRP 'bc', witness v0 | Lowest fees, modern wallets, recommended format |
| Taproot P2TR | Bech32m, witness v1, Schnorr signatures | Privacy and complex spending conditions (BIP 341) |
| HD Wallet (BIP 32) | Hierarchical derivation from seed | Multi-account wallets, mnemonic backup |
Limitations or considerations
These private keys are generated for educational purposes only. Never use them with real funds. Anyone who sees the private key (or the WIF string) controls all associated addresses. For real wallets, use a hardware wallet or a reputable software wallet that stores keys in encrypted storage.
This tool generates single key pairs, not HD wallets. Real Bitcoin wallets use BIP 32 hierarchical derivation from a BIP 39 mnemonic seed, allowing a single backup phrase to recover all addresses. For mnemonic generation, see the Mnemonic Phrase Generator. For seed phrase validation, see the Seed Phrase Validator.
The tool does not generate Taproot (P2TR) addresses, which require Schnorr public keys (BIP 340) rather than ECDSA. Taproot addresses use Bech32m encoding (BIP 350) with witness version 1.
The address validator checks format and checksum but does not verify that an address has been used on the blockchain or has a balance. For on-chain verification, use a block explorer like mempool.space or blockchain.com.
For the encoding layer used in Bitcoin addresses, see the Base58Check Encoder/Decoder. For Ethereum's checksum scheme, see the Ethereum Checksum Validator. For multi-chain address validation, see the Crypto Address Validator. For ECDSA signatures used in Bitcoin transactions, see the ECDSA Signature tool.
Frequently asked questions
What is the difference between Legacy, Nested SegWit, and Native SegWit addresses?
Legacy (P2PKH) addresses start with '1' and use Base58Check directly on the public key hash. Nested SegWit (P2SH-P2WPKH) addresses start with '3' and wrap a SegWit spend inside a P2SH script for backward compatibility. Native SegWit (P2WPKH) addresses start with 'bc1q' and use Bech32 encoding directly, offering the lowest transaction fees. All three derive from the same public key hash.
Why does Bitcoin use secp256k1 instead of secp256r1?
Satoshi chose secp256k1 for its simpler parameters and potential for faster implementation. Unlike secp256r1 (NIST P-256), which has unexplained constants in its curve equation, secp256k1 uses the equation y^2 = x^3 + 7 with no opaque parameters. Some view this as a trust advantage, since secp256r1's constants could theoretically contain a backdoor, though no evidence supports this.
What is Hash160 and why are two hash functions used?
Hash160 is RIPEMD-160(SHA-256(publicKey)). SHA-256 provides 256-bit security, and RIPEMD-160 compresses the output to 160 bits, which keeps addresses shorter (20 bytes instead of 32). Using two different hash functions also provides defense in depth: if either function were broken, the other would still protect the address.
Can I use the generated private key to receive Bitcoin?
Technically yes, but you should not. The key is displayed in plaintext in your browser. If anyone sees it, or if your browser is compromised, they can steal any funds sent to the derived addresses. Use a hardware wallet or a reputable software wallet for real funds. This tool is for understanding the derivation process.
What is WIF and why does it start with K or L?
WIF (Wallet Import Format) encodes a private key with a version byte (0x80 for mainnet) and a compression flag (0x01). Base58Check encoding of these 34 bytes produces a 52-character string. For mainnet compressed keys, the result starts with 'K' or 'L' due to the Base58 alphabet. Uncompressed WIF keys (without the 0x01 suffix) start with '5' and are 51 characters.
How does Bech32 differ from Base58Check?
Base58Check uses a 4-byte double-SHA-256 checksum and the Base58 alphabet (58 characters, omitting ambiguous ones). Bech32 uses a BCH error-detecting code with a 30-character checksum over a 32-character alphabet. Bech32 is case-insensitive (all lowercase) and can detect up to 4 errors with near-certainty, while Base58Check is case-sensitive and can miss some multi-character errors.
Conclusion
Bitcoin address generation is a deterministic pipeline from private key to public key to hash to encoded string. This tool shows every intermediate value so you can see exactly how a 32-byte random number becomes a '1...' or 'bc1q...' address. For the encoding primitives used here, see the Base58Check Encoder/Decoder and the Ethereum Checksum Validator. For multi-chain address validation, see the Crypto Address Validator. For the signature scheme used in Bitcoin transactions, see the ECDSA Signature tool.