What is Wallet Import Format (WIF)?
WIF is the base58check encoding used to write a Bitcoin private key as a short, typo-resistant string starting with 5, K or L. This tool converts a raw 64-character hex private key to WIF and back, adding the 0x80 version byte, the optional compression flag and the double-SHA-256 checksum. It runs entirely in your browser and is for learning and testing only.
What WIF is
A Bitcoin private key is really just a 256-bit number, usually written as 64 hexadecimal characters. That is awkward to copy and easy to mistype, so wallets store and export keys in Wallet Import Format instead: a shorter string of letters and numbers that starts with 5, K or L and carries its own built-in typo check. This converter turns a raw hex key into WIF and takes a WIF back to hex, doing the version byte, the compression flag and the checksum for you.
Everything happens in your browser. The checksum uses the WebCrypto API built into the browser, and nothing you paste is uploaded. It is a tool for learning how key encoding works and for testing, not for handling keys that hold real money.
How the conversion works
WIF is an example of base58check, the same encoding scheme Bitcoin addresses use. Three things are wrapped around the raw key before it is base58-encoded: a version byte that marks it as a mainnet private key, an optional flag that records whether the key is compressed, and a four-byte checksum that catches mistakes.
Decoding runs the same steps in reverse: base58-decode the string, split off the last four bytes, recompute the double-SHA-256 checksum over everything before them, and confirm the two match. If they do not, the WIF has a typo and the tool tells you rather than handing back a wrong key.
Compressed and uncompressed keys
Early Bitcoin used uncompressed public keys, and their WIF strings start with 5. Modern wallets use compressed public keys, which produce smaller addresses, and their private keys are marked with an extra 0x01 byte before the checksum. That single byte changes the leading character of the WIF to K or L. The private key number is identical either way: compression only affects how the matching public key and address are written, not the secret itself. When you decode a WIF here, the tool reports which kind it found.
A safety note worth repeating
This converter only reformats a private key. It does not derive the public key or address, because that needs secp256k1 elliptic-curve maths that is deliberately left out. More importantly, a private key is the sole control over any coins at its address, so anyone who sees it can spend them. Treat every key you experiment with here as disposable, generate throwaway values for testing, and never paste a key that holds real funds into this or any other website. If you want to understand the whole picture, the address side is covered by our Bitcoin address validator.
How we work it out
WIF = base58check(0x80 + 32-byte key + optional 0x01 compression flag), where the 4-byte checksum is the first 4 bytes of SHA-256(SHA-256(payload)). Decoding reverses this and verifies the checksum; a 38-byte payload means a compressed key, 37 means uncompressed.
Frequently asked questions
Is my key sent anywhere?
No. The conversion and the checksum maths run entirely in your browser using the built-in WebCrypto API. Nothing you paste is uploaded. Even so, this tool is meant for learning and testing, so never paste a private key that controls real funds into any website, including this one.
Why does WIF start with 5, K or L?
Those letters fall out of the base58 encoding of the 0x80 version byte. An uncompressed key encodes to a string starting with 5, while a compressed key (the modern default, with the extra 0x01 flag) starts with K or L. The tool detects which you have when decoding.
What is the compression flag?
It records whether the matching public key should be stored in compressed form, which is standard today and gives shorter addresses. It does not change the private key itself, only how the key and its addresses are represented. Compressed WIF has an extra 0x01 byte before the checksum.
What does the checksum protect against?
Typos. The last 4 bytes are a double-SHA-256 checksum of everything before them, so if you mistype a WIF the checksum will not match and the tool reports it as invalid rather than silently giving you the wrong key. This is the same base58check scheme Bitcoin addresses use.
Can I get a public key or address from this?
Not here. Deriving the public key and address needs secp256k1 elliptic-curve maths, which this converter deliberately leaves out. It only reformats the private key between hex and WIF. Treat any key you experiment with as disposable and never fund it.