Base64 private key → HEX, WIF, addresses

What this page computes

Some wallets, exchanges and OpenSSL-based tools never show a private key as 64 hex digits. They print the raw 32 bytes as Base64, because Base64 survives any text-only channel: JSON, INI files, chat messages, QR codes, clipboards. This page reverses that step — decode the text back into bytes, check that the result really is one valid secp256k1 private key, then run the whole derivation chain on it.

It never guesses: a decoded length that is not 32 bytes is an error, and an empty box produces an empty state rather than a result.

1. The Base64 alphabet, and why it holds 64 symbols

A private key is 32 bytes, and a byte can hold any of 256 values — roughly half of them control characters, quotes or bytes that are simply illegal in a text protocol. Base64 avoids all of that by re-grouping the bits into 6-bit chunks and mapping each chunk onto one of 64 harmless printable characters.

Why 64? Because 2⁶ = 64, and 6 bits is the largest chunk that still maps onto printable ASCII: 7 bits would need 128 symbols, and most of the upper range is control codes. The alphabet is fixed and public, and one character means one 6-bit value — nothing more:

26 + 26 + 10 + 1 + 1 = 64. Every 6-bit value from 000000 to 111111 has exactly one character, and every character has exactly one value. That is the entire trick.

2. Four characters carry three bytes — and where = comes from

6 bits per character and 8 bits per byte do not line up. The smallest common multiple is 24 bits: 24 = 3 bytes = 4 Base64 characters. Base64 therefore always processes input in 3-byte blocks and emits 4 characters per block, wasting no bits anywhere in the middle of the stream.

A 32-byte key is not a multiple of 3, so the final block is short and has to be padded. The arithmetic for the demo key is:

n = 32 bytes
full blocks = floor(32 / 3) = 10       -> 10 × 4 = 40 characters
leftover    = 32 mod 3      = 2 bytes  -> needs ceil(2·8 / 6) = 3 characters
padding     = 4 − 3         = 1        -> one "=" marker
total       = 40 + 3 + 1    = 44 characters = 4 · ⌈32/3⌉

That matches the sample exactly: 44 characters, ending in a single =.

The last two rows matter: a 32-byte and a 33-byte blob both encode to 44 characters. Only the = count separates them — one pad means n mod 3 = 2, none means n mod 3 = 0. Characters alone never reveal the byte length.

3. An encoding is neither encryption nor compression

• Encryption hides data behind a secret. Base64 has no secret: the alphabet is published in RFC 4648, the mapping is one-to-one, and anyone holding the string can decode it in one line of code. A Base64 private key is a plaintext private key.
• Compression shrinks data by exploiting redundancy. Base64 does the opposite — it always enlarges, because 8 bits of input cost 4/3 of a character. A uniformly random 256-bit key has no redundancy to exploit, so a "compressed" Base64 key is a contradiction.
• Encoding changes only the representation, so that bytes can travel through a channel which accepts only text. That is all Base64 does.

For this key size Base64 is the tightest text alphabet — 44 characters against 64 for hex — yet still 37.5 % larger than the raw bytes. It buys nothing in security, everything in compatibility.

4. Base64 next to hex, Base58 and Bech32

Bitcoin's ecosystem uses four text alphabets, and picking the wrong decoder is one of the most common ways to end up with a "key" no wallet recognises.

5. Where a Base64 private key actually comes from

Bitcoin Core itself exports WIF, not Base64. Base64 keys appear in the seams between Bitcoin and general-purpose software:

• OpenSSL / PEM key files. The file body is Base64 of an ASN.1 DER structure. Extracting the raw 32-byte scalar from it and re-printing it as Base64 is a standard migration path.
• Application config files. JSON has no byte type, so a service that stores a signing key in JSON almost always stores it Base64 — base64_encode() in PHP, base64.b64encode() in Python, Convert.ToBase64String() in .NET.
• Exchange and API exports. Some custodial services hand you a "raw private key" as Base64 rather than WIF, because their backend keys are not Bitcoin-specific.
• QR codes and printed backups. 44 characters fit a low-density QR symbol — though Base64 brings its own +// hazards.

6. Worked example — the demo key in every representation

These are the values this page produces for the sample Base64 in the input box:

Now change exactly one character — the leading C becomes a 0. Both are legal Base64 symbols, so the decoder has nothing to complain about:

The first byte moved from 08 to d0, and the key, both WIFs and every address changed with it. Base64 flagged nothing.

7. Base64 and WIF are not two spellings of the same thing

Both are text encodings of one 32-byte secret, and that is where the similarity ends. A WIF is Base58Check(0x80 ‖ key ‖ 0x01): it adds a version byte naming the network, a flag byte saying whether the key is used in compressed form, and a 4-byte double-SHA256 checksum. Base64 adds padding and nothing else.

The alphabets are the practical test. Base58 excludes 0, O, I and l so that handwritten paper wallets cannot be misread, and it excludes +, / and = as well. Base64 uses all of those. So a string containing +, / or = is not a WIF, and a string containing 0, O, I or l is not Base58 at all.

The reverse test is the dangerous one. Every Base58 character is also a legal Base64 character, and a compressed WIF is 52 characters — exactly divisible by 4. Paste KwVYL77Lcs1ckM39NvGjrtfKhU4KKdR2iB9Wq2FSMN6rbGK5tVqG into a Base64 decoder and nothing errors: it produces 39 bytes. Hence the length check here, and hence the byte count being a first-class result. A Base64 box that accepted a WIF would hand you a 39-byte "private key" that is not your key.

8. What this page rejects, and why

One subtlety: Base64 is not injective. In a partial final block the bits that do not fit are ignored, so for a 32-byte key …ehcco= and …ehccp= decode to identical bytes even though the strings differ, and decoders accept both. Never compare two Base64 keys as strings — decode first, then compare bytes.

9. Security notes and common mistakes

• Base64 is plaintext. Not obfuscation, not encryption, not a password: anyone who can read the string can spend the coins it protects.
• Never type a real key into a page you do not control. This page computes on the server you are already talking to and sends nothing elsewhere — but a funded key belongs in a hardware wallet or on an offline machine.
• No checksum means no typo alarm. If you must transcribe a key by hand, write it as a WIF and let its 4-byte checksum work for you.

• Treating Base64 as encryption or expecting it to be shorter than the raw bytes. "It looks like gibberish" is not protection, and 44 characters is still more than 32 bytes.
• Pasting a WIF or a PEM block. A WIF decodes (to 39 bytes) because Base58 is a subset of the Base64 alphabet; a PEM body decodes to DER, hundreds of bytes long.
• Using base64url data. JWT-style -/_ alphabets are not standard Base64; conversion is one substitution, but decoders reject them as-is.
• Comparing two Base64 keys as strings instead of comparing decoded bytes.

10. Quick reference