Private key → uncompressed WIF

What this page computes

You give it a 256-bit private key and it produces the uncompressed WIF — the original Wallet Import Format string: 51 characters, beginning with 5, with no compression flag inside it. This is the format every Bitcoin backup used before mid-2012, and the format still printed on old paper wallets.

Compare it with the modern form: the compressed WIF is Base58Check(0x80 ‖ k ‖ 0x01) — one byte longer, one character longer, a different checksum, and a completely different implied address.

1. The original WIF, from a time when a public key had only one shape

When the first Bitcoin client was written, a public key had exactly one serialization: the 65-byte 04 ‖ X ‖ Y form, produced by OpenSSL without any decision being made about it. There was no compressed form, no flag, and nothing to choose. A private key, therefore, needed to carry exactly one piece of metadata — which network (and therefore which coin) the key belonged to — and nothing else.

The design that resulted is minimal and, once seen, obvious:

• One version byte in front, 0x80 on mainnet, identifying the string as a private key rather than an address.
• The 32 raw key bytes, big-endian, zero-padded to a fixed width.
• A 4-byte checksum appended, so that a human transcription error is caught before a wallet ever tries to use the key.

The result was encoded in Base58 to keep it typeable and to avoid look-alike characters. That is the whole format. The name "Wallet Import Format" arrived later; the encoding itself was there from the early client. Note what is absent: no flag byte, because there was nothing to flag. This is not a "legacy mode" somebody designed for old keys — it is the original format, unchanged, and the 2012 compressed form was built as an extension of it.

2. Why dropping the flag changes the payload length, the first character and the checksum

The compressed and uncompressed WIFs of one key differ by exactly one byte inside the payload, and that single byte has four visible consequences.

Each of those follows mechanically:

• Length. Base58 encodes a big integer, and each character carries log₂58 ≈ 5.858 bits. 296 / 5.858 ≈ 50.5, so 37 bytes need at most 51 characters; 304 / 5.858 ≈ 51.9, so 38 bytes need at most 52. One extra byte costs exactly one extra character.
• First character. The leading Base58 digit is floor(value / 5850) for a 51-character string. A mainnet uncompressed WIF always begins with the byte 0x80, so its value lies in [2295, 2295 + 2288); with 5850 ≈ 2292.899 the quotient is between ≈ 4.29 and ≈ 4.32, which floors to 4 for every possible key — the character 5. On testnet the version byte is 0xef and the same arithmetic gives 9. 5 is not a convention; it is forced.
• Checksum. The checksum is the first four bytes of SHA256(SHA256(payload)), and the payload is what changed. Any change to the input produces an unrelated hash, so the four checksum characters at the end of the string bear no relation to the compressed version's.
• Address. The flag is a promise about which public key the wallet will derive. Without it, the wallet derives 04 ‖ X ‖ Y, hashes 65 bytes instead of 33, and lands on a different 20-byte commitment — a different address.

3. Full byte layout

The checksum computation is worth seeing in full for the demo key, because it is the step that ties the string to the key:

4. Why the 5… format is now considered legacy

Nothing about the format became invalid in 2012. What changed is the economics and the ecosystem:

So a 5… key is not broken, it is expensive and awkward. It cannot participate in SegWit's fee discount, it cannot back a Taproot output, and it pays roughly 32 extra virtual bytes of witness-discounted weight on every single spend for the rest of its life. Wallets therefore stopped producing it, and the address type it maps to is now labelled "legacy" — a word that describes popularity, not validity.

5. The sweep problem, in detail

This is the practical heart of the page. You have an old paper wallet, printed in 2011, with a 5… WIF and a 1… address, and you want to move the coins into a modern wallet. Three things can happen:

1. The wallet refuses the key outright. Many modern wallets — particularly descriptor-based ones and some hardware-wallet companion apps — only support compressed keys for imported accounts. They answer "invalid private key" or simply nothing. The key is fine; the software has no code path for it.
2. The wallet accepts it and shows a zero balance. The dangerously common case. The wallet imports the 32-byte key, assumes the compressed form (the only form it ever derives), computes hash160(02/03‖X), watches 146ZNjH7…-style addresses and finds nothing, because your coins are at the uncompressed address. Sweeping is impossible for the same reason: the wallet cannot sign for an output whose script commits to the 65-byte key.
3. The wallet accepts it correctly as a "legacy key" account, deriving and watching the uncompressed address and spending with the 65-byte public key. Some wallets do this properly; the feature is usually called "import legacy key", "sweep paper wallet" or "import uncompressed key".

A cousin of outcome 2 is worth calling out: a wallet that accepts the 5… key but silently "upgrades" it, deriving the compressed address as your receive address. Send coins there and your old paper-wallet balance and your new balance sit at two different addresses, only one of which the next wallet you open may watch. Always confirm that the address a wallet displays is the address you expect.

6. How to tell which form actually holds the coins

The first character of a WIF tells you what the exporter intended; it does not tell you where somebody paid. Those are different questions, and only on-chain data answers the second one.

Two practical heuristics: (a) a paper wallet's printed address and its printed key almost always match in form — a 5… key goes with an address built from the 65-byte public key; (b) when a restoration looks empty, never conclude anything from one address. Derive both, check both, and only then decide.

7. Worked example with the real demo values

These are the actual outputs for the sample key shown in the input box:

The address is the same Base58Check recipe applied to the 65-byte key, so its own payload can be shown too: version 00, hash160 3f0e966dc089c611a9c1d03bd4f69ea53b0223f9, checksum 3b0b7cbd, and the 34-character result 16kR3eiswUY6tmGnxZhwQmW6LAvTLGWG2G.

8. Round-trip verification

This page decodes its own output with Btc::wifDecode() and displays every recovered field in the result panel, so you can see that nothing was lost or invented: the original 32-byte key, false for the compression flag, version byte 80, mainnet, a valid b6f3d7f5 checksum and the 33-byte payload. Note the elegance of the decoder's rule — there is no explicit "uncompressed marker" byte. The length of the payload is the marker: 33 bytes means uncompressed, 34 bytes ending in 0x01 means compressed, and anything else is rejected.

9. Compressed vs uncompressed WIF

10. Security notes

• A 5… WIF is a plaintext private key. Base58 is an alphabet change, not encryption. Anyone who photographs the paper wallet, reads the QR code or sees your screen can spend the coins.
• The checksum protects against typos only. Four bytes of SHA256d catch transcription mistakes; they say nothing about who created the string or whether the key was generated honestly. A "perfectly valid" WIF can belong to an attacker.
• Old keys have had a long time to leak. A key that sat in a 2011 wallet file, an emailed backup or a cloud album has been exposed to many attack surfaces for a decade. When sweeping, move the full balance to a freshly generated address in one transaction, and never reuse the old key.
• Watch out for "sweep" services. Any website offering to sweep a paper wallet is asking you to hand over the private key. That request is the theft vector. Sweep with software you control, offline if possible.
• Sweep to the right form. Make sure the destination is an address you have backed up (a seed-derived one), not the compressed address derived from the very paper key you are retiring.

11. Common mistakes

• Assuming a 5… WIF is invalid because modern wallets reject it. It is original-format, correct and spendable; the software simply lacks support.
• Assuming a zero balance means the coins are gone. It usually means the wallet derived the compressed address. Compute both.
• Thinking the key has to be "upgraded". A key has no version and no state; only the coins can be moved. The WIF is just how the key is written down.
• Using the compressed WIF of an old key by mistake. It produces a valid but different address — the cleanest way to make real coins look lost.
• Truncating the WIF to 51 characters by hand. A 33-byte and a 34-byte payload hash differently, so a hand-trimmed string fails its checksum.
• Expecting SegWit from a 5… key. Witness v0 requires a compressed key, so bc1q… addresses are out of reach.

12. Quick reference