Private key → compressed WIF

What this page computes

You give it a 256-bit private key and it produces the compressed WIF — the Wallet Import Format string that starts with K or L, is 52 characters long, and tells a wallet to derive the compressed public key from that key. WIF is not a new secret and not a new kind of key: it is your private key, plus two bytes of metadata, plus a checksum, written in Base58.

Every part of that chain is shown separately in the result panel above: the payload, each of its fields, the hash, the checksum, and the final string.

1. What Base58 is, and why the alphabet skips 0 O I l

Base58 is positional notation in base 58 — like decimal or hexadecimal, but with a hand-picked alphabet of 58 characters. Encoding a byte string means treating it as one huge integer and repeatedly dividing by 58, collecting remainders; decoding reverses that. The alphabet is case-sensitive and free of punctuation, so a string can be read aloud, typed from a printed page or embedded in a QR code without quoting or escaping.

Those four omissions are the entire point of the alphabet. Bitcoin keys and addresses are transcribed by humans — off a screen, a paper backup, a metal plate — and the likeliest transcription error is 0↔O or 1↔I↔l. Deleting the ambiguous glyphs removes a whole class of mistakes instead of merely detecting it later.

• Leading zero bytes become 1. A raw big integer loses leading zeros, so Base58 encodes each leading 0x00 byte as a literal 1 (alphabet index 0). That is why every mainnet P2PKH address — version byte 0x00 — begins with 1.
• A WIF never starts with 1. Its first byte is 0x80, whose high bit is set, so there is no leading zero byte to encode.

2. Why there is a checksum, and exactly how it is computed

Base58 alone has no error detection: change one character and you get a different, perfectly well-formed number — which for a private key means another key, or a string some wallet rejects with a cryptic error. Bitcoin therefore appends four checksum bytes before encoding, a scheme called Base58Check:

SHA-256 is applied twice (the SHA256d used for block hashes and transaction IDs), truncated to 32 bits, and appended to the payload. On import a wallet recomputes it and compares. For the demo key the whole computation is visible:

The checksum is only 32 bits, so a random corruption slips through with probability 2⁻³² ≈ 1 in 4.29 billion — long enough to kill typos, short enough to cost four bytes. Change one character of the demo WIF and this page's decoder answers "WIF checksum is invalid (typo or truncated string)" instead of silently returning a different key.

3. The payload: 33 bytes of data, 34 with the flag

WIF is defined as a Base58Check encoding of a payload that begins with a version byte. For a compressed key the payload is 34 bytes long, and each byte has a job:

The version byte identifies the coin and the key type, and it is what makes the resulting string recognisable at a glance:

Notice the last two rows: 0x00 and 0x05 are address version bytes, not key version bytes. Three version-like bytes appear across one derivation chain — 0x04 the SEC1 point tag, 0x80 the WIF version, 0x00 the P2PKH version — and mixing them up is a classic confusion.

4. Why compressed WIFs are 52 characters and start with K or L

Base58 is a big-integer encoding, so the length of the output is set by the size of the number: each Base58 character carries log₂58 ≈ 5.858 bits. A 38-byte value is 304 bits, and 304 / 5.858 ≈ 51.9, so at most 52 characters are needed. A 37-byte value is 296 bits and 296 / 5.858 ≈ 50.5, giving at most 51 characters. That single byte — the compression flag — is exactly what moves the WIF from 51 to 52 characters.

The first character is a stronger statement. The first Base58 digit is floor(value / 5851), and a mainnet compressed WIF always begins with the byte 0x80, so its value lies in [2303, 2303 + 2296). With 5851 ≈ 2298.757 the quotient is always between ≈ 18.93 and ≈ 19.08, which can only floor to 18 or 19 — the alphabet positions of K and L. For an uncompressed mainnet WIF the value lies in [2295, 2295 + 2288) and 5850 ≈ 2292.899, giving a quotient between ≈ 4.29 and ≈ 4.32 that always floors to 4 — the character 5. The leading character is not a convention; it is forced by the arithmetic.

A random sample of 400 freshly generated keys on this server produced 184 WIFs starting with K and 216 starting with L, all 52 characters long; 300 uncompressed WIFs from the same keys were all 51 characters and all began with 5. The K/L split is essentially a coin flip, because it depends on the high bits of the random key.

5. Why the 0x01 flag lives inside the WIF

When compressed keys were introduced in 2012 (see the uncompressed key page for the history), wallets had a problem: a backup of a private key was a single string, and the wallet had to know which public-key serialization to derive. A separate field would have broken every existing parser, printed paper wallet and QR code. Instead the payload grew by one optional trailing byte:

• The slot was free. The 32-byte key has a fixed length, so an optional byte after it is unambiguous: a 33-byte payload means "uncompressed", a 34-byte payload ending in 0x01 means "compressed".
• The flag is covered by the checksum. It sits inside the hashed region, so a corrupted or maliciously flipped flag is caught like any other typo. Stored outside the string it would carry no integrity protection at all.
• The flag is a hint, not key material. It changes no bit of the private key; it only tells the wallet which public-key encoding to hash — and therefore which address to look at.

6. How a wallet uses the flag to decide which address to spend from

That branch is the whole point. The flag does not merely affect how the wallet prints your key; it changes the 20-byte hash the wallet watches on-chain and the public key it pushes when spending. With the flag it derives hash160(02/03‖X) and pays to 146ZNjH7…; without it, hash160(04‖X‖Y) and 16kR3eis…. Both are correct addresses for the same key — just different ones.

7. Worked example — every value computed and verified

All of the following are the real outputs for the sample key in the input box:

Note the checksum difference between the two forms: 3a0a0417 versus b6f3d7f5. Appending the flag byte changes the hash input, so it changes the checksum and the last four characters of the two strings are unrelated — a useful sanity check when comparing two WIFs of the same key by eye.

8. Round-trip verification

An encoding that cannot be decoded is worthless, so this page decodes its own output with Btc::wifDecode() and shows every field it recovers in the result panel: the identical 32-byte key, the compression flag set, version byte 80, network mainnet, a valid checksum, and the 34-byte payload that went in. Base58Check is a bijection, so the round trip must return the original bytes. If a tool decodes your WIF to a different key, the string was mistyped or the tool is broken — there is no third possibility.

9. Compressed vs uncompressed WIF, side by side

See private key → uncompressed WIF for the mirror-image page and WIF → private key HEX for the decoder that tells you which form a string you were given actually is.

10. Security notes

• A WIF is the private key in plain text. Base58 is an encoding, not encryption. Anyone who sees the string can spend the coins, irreversibly.
• The checksum detects accidents, not attacks. It says nothing about who created a key, and it stops nobody from recomputing a valid checksum for a key of their own choosing.
• Be careful where you paste it. WIF strings are the standard payload of phishing sites, clipboard malware and chat scams. Type a paper wallet's key into software you own, ideally offline.
• A WIF is a single key, not a wallet. Imported into an HD wallet it becomes a standalone, non-derived account: no seed phrase, no xpub, no change addresses, no SegWit or Taproot addresses. If you sweep it, sweep the whole balance to a key you have actually backed up.
• This page sends your key to the server. The request is a plain HTTP GET, so treat every test here as public: use the demo key or another throwaway key, never one protecting real money.

11. Common mistakes

• "Base58 hides my private key." It does not; it is a lossless transformation any decoder reverses in microseconds.
• Reading the 0x01 flag as part of the key. The key is 32 bytes, the flag is metadata. Keeping the flag yields a 33-byte "private key", which is invalid.
• Confusing the version bytes. 0x80 is a WIF, 0x00 a P2PKH address, 0x04 an uncompressed public key tag — same byte position, three unrelated meanings.
• Expecting a 5… and a K… WIF of one key to give the same address. They never will — that is the entire purpose of the flag.
• Hand-editing the last four characters. Those are the checksum; change anything in the string and they must be recomputed. Typing over them is how people "lose" keys that were fine.
• Treating a WIF as a seed phrase. It encodes one key at one derivation position; it cannot generate a family of addresses and it is not a BIP39 mnemonic.

12. Quick reference