Decimal private key → HEX, WIF and addresses

What this page computes

This page takes the private key written the way a human writes numbers — as an ordinary decimal integer — and converts it into the canonical 256-bit hexadecimal form, then runs the whole derivation from there. Spaces, commas and underscores are stripped before conversion, because 3 683 455 675 … and 3,683,455,675… and 3683455675… are the same number and a human reader needs the separators while a computer does not.

1. Decimal and hex are the same number

A private key is an integer, and an integer has exactly one value. "Decimal" and "hexadecimal" are not properties of the key; they are choices of how to spell it. The value is a weighted sum of digits, where the weight of each position is a power of the base:

For the demo key the first decimal digit is 3 in the 76th position, contributing 3 × 1075; the hex form starts with 08, contributing 0 × 1663 + 8 × 1662. Different arithmetic, identical value.

The reason hex is the convention is in the third column: base 16 is the only one of these that lines up with the machine's own unit. Four bits are one hex digit, eight bits are two hex digits, so a 32-byte key is exactly 64 hex digits, and every byte boundary is visible by counting.

2. How the conversion actually works

Two textbook algorithms do the job. Both are exact; they differ in how much scratch memory they need and how they feel to implement.

digits = "0123456789abcdef"
out = ""
while n > 0:
    n, r = divmod(n, 16)     # r in 0..15
    out = digits[r] + out   # prepend
return out or "0"

acc = 0
for ch in decimal_string:
    acc = acc * 10 + digit(ch)
# acc is now the integer value;
# repeat the same trick with base 16
# to emit hex digits.

Both algorithms are equally correct, and both are linear in the number of digits for fixed-size bases. The reason this page can do it at all in PHP is that the work is delegated to GMP: gmp_init("368345…", 10) reads the decimal string directly, and gmp_strval(n, 16) writes the hex out. Doing it by hand with intval() would silently destroy the key — see the next section.

3. Why 256 bits, and where the boundaries are

secp256k1's point group has order n, which is a 256-bit number just below 2256. Valid private keys are the integers 1 … n−1. Written out in full, because these are the exact numbers a validator compares against:

Only three decimal digits distinguish n−1 from n in that table. The closed invalid interval [n, 2256−1] contains 432420386565659656852420866394968145599 integers — the span between its two endpoints is 432420386565659656852420866394968145598. Dividing 2²⁵⁶ by that count gives 267776665566007192515705986938822075896, so the band is only about one 2.678 × 10³⁸th of the 32-byte space. That is why nobody notices the boundary until a validator rejects an input.

4. BigInt: why ordinary integers cannot hold this

Every language's native integer type has a fixed width, and 256 bits is four times the widest one in common use. The consequences are not hypothetical:

5. Width, padding and the leading zeros

A decimal number has no fixed length: 1, 256 and the demo key are all "a private key" as far as decimal notation is concerned. Bitcoin, however, serializes a key as exactly 32 bytes, so the value must be left-padded with zero bits until it fills the field:

The demo key happens to need no padding at all: its 64th hex digit from the right sits in the top nibble position, so its byte count is exactly 32 and its leading-zero-byte count is 0 — even though its first four bits are 0000. This distinction (leading zero bits vs leading zero bytes) is the single most common source of confusion when people hand-write binary keys.

6. Round numbers: the shape of the famous "puzzle" keys

The Bitcoin ecosystem has a well-known set of funded addresses — the "puzzle" — whose private keys are not random 256-bit numbers at all: key number i is a number in the interval [2i−1, 2i). In other words the top 256 − i bits are known to be zero. Those keys are exactly the "small round decimal numbers" this page is about, and the table below shows the first ones with the mainnet P2PKH address each one derives (all values computed by this tool):

Two lessons follow, and they explain why such keys are emptied almost instantly:

• A known interval shrinks the search. If you know the key lies in [2i−1, 2i), the candidates number 2i−1 instead of 2256. Against a known interval, Pollard's kangaroo algorithm costs on the order of 2i/2 point additions: for i = 40 that is about a million operations, for i = 64 about 2³² (a laptop-week), for i = 128 it is 2⁶⁴ and out of reach. The low members of this table are arithmetic exercises, not puzzles.
• Recognisable addresses make it worse. These keys are published, so their addresses are on a public list: a sweeper does not search at all, but watches the addresses and spends in the same block a deposit lands in. A "clever" key such as n itself or 2255 (which derives 18h7RmwXCTYX69z9S2Hc9gs8ET7SUN7YG5) is in the same category.

7. Worked example

Everything in this table is produced live by the page from the decimal sample 3683455675284633286911943861444039993120875154046227415438637967083965608394 (76 digits, about 3.18 % of the way up the valid range):

8. Input validation, and the messages you will see

9. What comes next in the chain

• HEX private key → everything — the hub page: all representations, both WIFs, all ten addresses in one screen.
• Binary private key — the same key as 256 bits, with bit positions.
• Base64 private key — for wallet exports that are neither hex nor decimal.
• Private key → compressed public key — the step after the conversion.

10. Security notes

• Decimal keys are still keys. Writing a secret in base 10 hides nothing; a key published as a decimal integer is as exposed as the WIF.
• Copy the exact digit count. A 76-digit key with one digit missing is a different key, usually a valid one, and it will show a balance of zero while your real coins sit untouched — or, far worse, an attacker's key that was generated by a search for near-miss typos.
• Never round or reformat. Thousands separators are cosmetic, but "3.68 × 10⁷⁵" is information loss. Keep keys as strings, and back them up as a WIF or a BIP39 mnemonic rather than a number you retyped.
• Remember the point of the exercise. Everything on this page is public mathematics: anyone who has the decimal key can spend the coins, and anyone who has an address cannot find the key. That asymmetry is the whole security model.

11. Common mistakes

• Treating the decimal form as "more secret". It is the same value; obscurity is not encryption.
• Using intval() / Number() / parseInt(). They truncate at 63 or 53 bits and return a valid-looking wrong number.
• Confusing 256 (a number) with 256 bits (a width). The key 256 is 0000…0100, a perfectly ordinary low-entropy key.
• Assuming the maximum is fixed. 2256−1 is not a key; n−1 is. The upper bound is the curve order, not the width of the field.
• Padding with the wrong side. Padding is always on the left. Appending zeros multiplies the value by 16.
• Pasting a WIF or hex string here. A K… string or 0824c314… is not a decimal integer and will be rejected — use the matching page.

12. Quick reference