Validate Bitcoin addresses (P2PKH, P2SH, Bech32, Bech32m). Detect address type and check Base58/Bech32 checksums.
This tool decodes a pasted Bitcoin address and works out which encoding it uses - Base58Check for legacy P2PKH and P2SH addresses, or Bech32/Bech32m for native SegWit and Taproot outputs - then recomputes the checksum to confirm it matches what's encoded. It reports the detected type (P2PKH, P2SH, P2WPKH, P2WSH, or P2TR) and whether the checksum passes. What surprises people: a passing checksum only confirms the address is well-formed, not that it belongs to the intended recipient or has ever been used.
A concrete input and expected output from the current implementation.
Input
1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
Expected output
Type: P2PKH (legacy), Base58Check checksum: valid, version byte: 0x00 (mainnet)
Decoding this address from Base58 yields a leading 0x00 version byte (mainnet P2PKH) followed by a 20-byte hash and a 4-byte checksum; the double-SHA256 of the version+hash matches that checksum, so it validates. This is Bitcoin's well-known genesis block address.
For addresses starting with 1 or 3, the tool decodes the Base58 alphabet back into bytes, splits off the leading version byte and trailing 4-byte checksum, then runs double SHA-256 over the version-plus-payload bytes and compares the first four resulting bytes against the checksum. A mismatch flags a typo or corrupted address rather than a network error.
For addresses starting with bc1, the tool separates the human-readable prefix from the data part, maps each character through the Bech32 charset into 5-bit groups, and verifies the checksum polynomial. Per BIP-350, witness version 0 must use the original Bech32 constant while versions 1 and above (including Taproot) must use the Bech32m constant, so the check is version-aware.
No. A passing checksum only means the address is correctly encoded - it does not confirm the address belongs to your intended recipient, that it's controlled by a working wallet, or that it hasn't been tampered with elsewhere (e.g. clipboard-hijacking malware). Always verify the address through a second channel.
Taproot outputs use witness version 1 and, per BIP-350, must be checksummed with the Bech32m constant, not the original Bech32 constant used for version-0 SegWit addresses. An address with the wrong variant for its witness version will fail validation even though every character is spelled correctly.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.