Bitcoin Keypair Calculator

Enter a Private Key

Type or paste any 64 hex characters (0–9, a–f) representing a 256-bit private key. Every intermediate value — public key, hashes, address, WIF — is computed instantly in your browser using the same secp256k1 algorithm as the original Bitcoin client.

Try changing a single character and watch every downstream value change completely. This demonstrates why each private key produces an entirely unique, unpredictable address.

How to Use This Tool

Experimenting with small changes

Because secp256k1 elliptic curve multiplication is a one-way function, changing even a single hex digit of the private key produces a completely different public key and address. There is no pattern or predictability. Try:

• Load the Wiki example key, then change the last character from d to e — every result changes entirely
• Use k=1 (private key ending in 01) — the public key is exactly the secp256k1 generator point G itself
• Use k=2 — the public key is 2G (the point doubling of G), showing how the curve operation works
• Try incrementing the last byte through 01, 02, 03… to see how completely unrelated each result is

Uncompressed vs compressed addresses

The same private key produces two different valid Bitcoin addresses — one derived from the uncompressed public key (65 bytes, prefix 04) and one from the compressed public key (33 bytes, prefix 02 or 03). Modern wallets use compressed keys. The WIF format tells Electrum which to use: a 5… WIF imports as uncompressed, while a K… or L… WIF imports as compressed. Make sure you know which address your funds are on before importing.

What the x and y coordinates tell you

The public key is a point on the elliptic curve — it has an x coordinate and a y coordinate, both 32 bytes. The compressed public key prefix is determined purely by whether y is even (02) or odd (03). You can see this by watching the y coordinate and compressed prefix as you try different keys.

Verifying results

To verify any address, paste it into mempool.space. Valid addresses will show a valid (empty) wallet page. You can also import the WIF key into Electrum to confirm it derives the matching address.

Valid Private Key Range

Not every 64-character hex string is a valid Bitcoin private key. The value must be:

• Greater than 0000…0000 (not zero)
• Less than the secp256k1 curve order n:

Also note: 0000…0001 (k=1) is technically valid but obviously not safe to use as a real wallet — its address is publicly known.

One Private Key, Two Addresses — A Brief History (by Claude Sonnet 4.6)

In Bitcoin's earliest days (2009–2011), Satoshi's original client used only the uncompressed public key format — the full 65-byte 04 + x + y form you see in the calculator above. Every address generated in that era was derived from this longer form, and there was no choice to make. The compressed format was defined in the underlying secp256k1 elliptic curve standard, but Bitcoin simply didn't use it.

Compressed public keys arrived in late 2011 and early 2012. The motivation was straightforward: a compressed key encodes the same point on the curve in 33 bytes rather than 65, because the y coordinate can always be recalculated from x — you only need to store whether y was even or odd (the 02 or 03 prefix). Every transaction broadcast to the network must include the public key, so the saving of 32 bytes per transaction, compounded across millions of transactions, adds up to a meaningful reduction in blockchain bloat.

This created an awkward transition period. The same 64-character hex private key now implicitly controlled two completely separate Bitcoin addresses — one derived from the uncompressed public key, one from the compressed — and different tools defaulted to different conventions. The solution was to encode the choice directly into the WIF (Wallet Import Format) itself: a 5… WIF tells any wallet to derive the address from the uncompressed key, while a K… or L… WIF signals to use the compressed form. The raw private key bytes inside are identical; only the wrapper differs. This meant a WIF was always self-describing, and a wallet importing one could never derive the wrong address — as long as the correct WIF format had been recorded in the first place.

In practice, the two-format transition caused genuine confusion through roughly 2012–2015. Users who generated an address with one tool and then imported into a wallet with a different default would see a zero balance, with no obvious explanation. By around 2013–2014 the ecosystem had largely settled on compressed keys as the default for new wallets, and the later arrival of BIP32 seed-phrase wallets made the raw hex workflow mostly obsolete for ordinary users — the seed phrase standard specifies the derivation path and key format unambiguously, so the ambiguity simply doesn't arise. Uncompressed-format addresses from the Satoshi era remain perfectly valid and spendable on the network today; they just aren't something any modern wallet would generate.