Binary private key → HEX, WIF and addresses

What this page computes

This page accepts the private key as raw bits — up to 256 characters of 0 and 1 — and shows what every one of those bits does. Spaces, tabs, newlines, colons, dashes and underscores are ignored, so you can paste a key in whatever layout your source used. The bits are then regrouped into bytes, converted to hex, and the full derivation runs from there.

This is the only page in the set where you can see which bit produces which address, because binary is the one representation that does not hide the machine's own unit of work.

1. Bit, nibble, byte, word

The units matter because every conversion on this page is a regrouping of the same bits:

The relationship is exact and has no remainder: 8 bits are always 2 hex digits, 4 bits are always 1, and 256 divides evenly by both. That is the entire reason hexadecimal exists in this domain — it is a lossless human-readable view of binary, not a separate number system with its own rules.

2. Binary → hex, digit pair by digit pair

The conversion is done by nibble grouping, and it never requires arithmetic on the whole number:

for each group of 4 bits (left to right):
    value = 8*b3 + 4*b2 + 2*b1 + 1*b0      # 0..15
    emit  "0123456789abcdef"[value]

Applied to the demo key's first four bytes:

bits   0000 1000 0010 0100 1100 0011 0001 0100
hex      0    8    2    4    c    3    1    4
                 ↑
        byte 0 = 0x08 · byte 1 = 0x24 · byte 2 = 0xc3 · byte 3 = 0x14

Note that this page pads your input on the left to the next byte boundary before converting, and then the key validator pads again to a full 32 bytes. Typing 1 is therefore the key 1 — not 0x10, and not an error. Left is the most-significant end, and that is the rule for every fixed-width integer in Bitcoin key material.

3. Big-endian and little-endian

"Endianness" is only a question when a multi-byte value is written to a byte sequence: do the significant bytes come first or last? Bitcoin is famously inconsistent about it, and the inconsistency is a top source of interoperability bugs.

4. Why leading zeros carry meaning

In ordinary arithmetic 0001 and 1 are the same number, and many programming languages will happily agree. In a serialized key they are not the same bytes, and the byte count is fixed by the protocol at 32. A key's leading zeros are therefore data: they say "this key is small", and dropping them shifts every following bit to the left.

The demo key illustrates the subtlety: it has 0 leading zero bytes but 4 leading zero bits, because its first byte is 0x08. Both counts are reported on this page, and mixing them up is the most common mistake when people hand-type binary keys.

5. Entropy, bit balance and Hamming weight

The Hamming weight of a key is simply how many of its 256 bits are 1. For a uniformly random key each bit is an independent fair coin, so the weight follows a binomial distribution with mean and spread:

So roughly 68 % of random keys land in 120–136, and 99.7 % in 104–152. The demo key's weight is 116 — 1.5 σ below the mean, entirely unremarkable. What matters is that you did not choose it: a key with a deliberately balanced weight has less than 256 bits of entropy, because you excluded most of the space.

6. How key-search programs exploit known bit patterns

Brute force against a full 256-bit key is hopeless: 2256 candidates. Search programs do not attack random keys; they attack keys whose shape is known. Three shapes are common, and all three are visible in the binary representation of a key:

Concretely: a key with the top 128 bits known to be zero leaves 2128 candidates and costs about 264 point additions — still out of reach today. A key with the top 200 bits zero leaves 256 candidates, about 228 ≈ 268 million additions: a single GPU for minutes. That is the actual reason the well-known "puzzle" addresses are emptied so quickly — their keys are known to be small, so the search is over an interval, not over the space.

7. Worked example

The 256 bits below are the demo key, and every hex, WIF and address value in this table is produced live by this page:

Two facts worth internalising from this table. First, flipping the final 0 bit to 1 would change the private key by one, and would change every single derived value — the public key, both hashes and all ten addresses — beyond recognition. There is no "almost the same key" in Bitcoin. Second, the visual structure of the bits (00001000 00100100 …) tells you nothing about the address: the mapping from bits to address is deliberately unstructured, which is what stops an attacker from searching "nice-looking" keys instead of the whole space.

8. What comes next in the chain

• HEX private key → everything — the hub page, all ten addresses at once.
• Decimal private key — the same key as one big integer.
• Base64 private key — for wallets that export raw bytes as text.
• Private key → compressed public key — where the bits become a curve point.
• BIP39 mnemonic → BIP32 child key — how a safe key is generated in the first place, instead of typed as bits.

9. Security notes

• Binary is the most dangerous representation to handle by hand. One missing or extra 0 shifts everything after it; there is no checksum and no structure to notice. If you must move a key between machines, move it as a WIF (which carries a checksum) rather than as bits.
• Copy-paste, never retype. A 256-character string is beyond reliable human transcription; every character has a 1-in-2 chance of being wrong if you guess.
• This page is a teaching tool. It has no key generation, no wallet and no storage. Any key you type here should be considered public from the moment you type it.
• Bit-pattern "optimisation" is a self-inflicted attack. Fixed prefixes, repeated nibbles, low weights and round numbers are all first-class targets for the algorithms in section 6.
• Entropy cannot be seen in the bits. A key whose binary looks wonderfully random can still be SHA256("hunter2"). The visual test proves nothing; only the generation process does.

10. Common mistakes

• Entering 255 or 257 bits. Both are rejected or padded in ways that change the key. Count the characters (or let the page report the bit length, which it does).
• Right-padding instead of left-padding. Bits are written most-significant first; adding 0 on the right multiplies by 2, adding it on the left does nothing at all.
• Reading the bits backwards. A big-endian byte order applies to key material; reversing it produces a different valid key with a different address.
• Assuming "all zeros" is a weak key rather than an invalid one. It is rejected outright: 0 · G has no coordinates.
• Assuming "all ones" is the strongest key. 2256−1 is larger than the curve order and is rejected too.
• Confusing bits with bytes when counting length. "256" is neither; the key is 256 bits, 32 bytes and 64 hex digits.
• Thinking the binary view is a different key. It is the same integer; only the page's input format differs.

11. Quick reference