HEX private key → every format, address and WIF

What this page computes

This is the master calculator of the tool set. You give it one 256-bit integer — the private key k — and it returns every standard representation of that integer, both Wallet Import Format strings, both public-key serializations, the elliptic-curve point behind them, both hash160 commitments and ten addresses (five mainnet, five testnet).

Everything here is a pure function of k: no seed, no password, no server state, no network call. Anyone who types the same 64 hex digits gets byte-identical results, forever.

1. The private key: one number, many spellings

A private key is not a file, a string or a blob of random bytes. It is an integer — a scalar — distinguished from other keys only by its value. How you write that value down is a representation:

Hex and decimal name the same number, so converting between them is lossless. Base64 and WIF add a second ingredient — raw bytes, or bytes plus version byte and checksum — so they are not "just another base".

2. Why 256 bits, and why k cannot be 0 or n

secp256k1 lives over a 256-bit prime field, and the group generated by G is cyclic of order n. Three hard boundaries follow:

• k = 0 gives 0 · G, the point at infinity: no coordinates, nothing to serialize. Every validator rejects it.
• k ≥ n wraps: n · G = ∞, so (n+1) · G = G. A 32-byte value equal to n + 1 looks normal and behaves like the key 1.
• The largest 32-byte value, 2256 − 1, is also invalid — it exceeds n.

The gap between the last two rows is 432420386565659656852420866394968145598 — nothing observable marks it, which is why nobody notices until a validator throws.

3. From number to point: the public key

Multiplying G by k gives a point P = (X, Y) on y² = x³ + 7 (mod p): the public key. A point has two coordinates, so it serializes in more than one way — and the choice changes every address that follows.

Compression is lossless: Y² = X³ + 7 has two solutions, Y and p − Y, always of opposite parity, so one bit — the 02/03 prefix — picks between them. Recovery is closed-form because p ≡ 3 (mod 4): Y = (X³ + 7)(p+1)/4 mod p, negated when the parity does not match.

4. WIF: the same key with a network tag and a checksum

WIF (Wallet Import Format) is Base58Check over a small payload:

compressed:   0x80 ‖ k(32 bytes) ‖ 0x01     → 34-byte payload → 52 characters
uncompressed: 0x80 ‖ k(32 bytes)             → 33-byte payload → 51 characters

5. hash160: the 20-byte commitment

The intermediate values for the demo key, so nothing is hidden:

Two reasons are usually given: it shortens the address, and it hides the public key behind a hash for any address that has never spent — which matters because the public key is what a quantum computer running Shor's algorithm could attack directly. The trade-off is a 160-bit commitment, far weaker against collisions than the curve itself, though a collision alone does not let anyone spend your coins.

6. One key, five addresses

All five come from the same private key, but they commit to different bytes and are spendable by different scripts.

• C and U share one script type. Witness programs accept only compressed keys, so modern wallets derive C; U survives because coins paid to it before 2012 must stay spendable.
• S is a wrapper: the 22-byte 0x0014 ‖ h160 redeemScript, hashed into a 3… address so old wallets could pay into SegWit.
• W is the modern default for single-key wallets: the address is the witness program, so the scriptPubKey and the fee are the smallest of the first four.
• T is a different construction. The x-only internal key is tweaked with TapTweak (demo tweak bae9168523281e7f9e91d897a8d23f7ae6fe66d61854019dcb8abb5185e8fa4d, output key dc07734d9b91d7231b8574b459ad8e65d8351c1c4930ad2e171447297bde59a3). Taproot never hashes the key down to 20 bytes, so a hash160 tool cannot produce it.

7. Checksums: protection from a typo

Base58Check detects errors but cannot correct them. Bech32 also forbids mixed case and caps length at 90 characters, so typos surface.

8. Testnet: same key, different prefixes

146ZNjH7… and micWfnN6… commit to the same 20-byte hash160; only the version byte differs. Treat the prefix as part of the payment instruction, not as decoration.

9. Worked example, end to end

Produced by this page from the sample key 0824c314772b2c2859c889471390a36bf66e53a1ca1642f96f0f2c9307a171ca:

10. What comes next in the chain

• Decimal private key and binary private key — the same number written two other ways.
• WIF → private key — the reverse direction, including the checksum test.
• Private key → compressed public key — P = k·G explained on its own.
• hash160 → addresses and Bech32 decoding — after the hash.

11. Security notes

• Entropy, not cleverness. Keys must come from a CSPRNG, a hardware RNG or a BIP39 mnemonic; human-chosen phrases, timestamps and counters are enumerable.
• Address reuse is a privacy leak. Spending publishes the public key and links later payments to it; modern wallets derive a fresh address per payment (BIP32/44/84/86).
• Verify a printed address, not a screenshot. Clipboard-swapping malware is today's most common self-custody theft vector.
• Testnet keys are not safe to publish: the "testnet version" of a mainnet key is the same scalar.

12. Common mistakes

• Expecting one address. One key produces five mainnet and five testnet addresses; a wallet shows the type it was built for.
• Pasting a WIF where hex is expected. A K…/5… string is Base58Check, not hex — decode it first (WIF → private key).
• Dropping leading zeros. 824c314… instead of 0824c314… shifts every byte by a nibble; this page left-pads short input, which hides the error.
• Reading a checksum as proof of ownership. It only means the string was not garbled: 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH is valid, its key is 1, and it is empty.
• Treating the public key as the address. The address commits to a hash of the encoded key, or to a script built from it; the conversions are one-way.
• Confusing p with n. Coordinates are modulo p = FFFF…FC2F; keys live in [1, n−1] with n = FFFF…4141.

13. Quick reference