QbyteLab

Key takeaways

• A WIF is a Base58Check encoding of your raw 32-byte private key, wrapped with a version byte, an optional compression flag, and a 4-byte checksum.
• The single 0x01 compression byte changes the public key, so one private key can produce two completely different Bitcoin addresses.
• A WIF that starts with 5 is uncompressed; one that starts with K or L is compressed on mainnet.
• Never paste a private key into an unknown website; convert it on a device that is offline, because a live page can quietly capture what you type.

A WIF to address conversion decodes a Wallet Import Format string back into a raw private key, derives the matching public key, and hashes that into a Bitcoin address. The safe way to do it is on a device that is offline, because a private key typed into a live web page can be captured before you ever see the result.

This guide explains what a WIF is, how the compression flag quietly changes which address you get, and how to run the conversion without exposing your key. It ends with a worked example using a well-known test key that holds no funds, so you can follow along with zero risk.

What a WIF Is and How It Encodes a Private Key

A Bitcoin private key is just a 256-bit number, 32 bytes of raw data. On its own it is an unreadable blob of hex. Wallet Import Format, or WIF, is the human-friendly wrapper that wallets use to export and import that number.

WIF uses Base58Check encoding, the same scheme Bitcoin uses for addresses. Base58 drops characters that are easy to confuse, such as the digit 0, capital O, capital I, and lowercase l, and the "Check" part appends a checksum so a single mistyped character is caught instead of silently pointing at the wrong key. The Bitcoin Wiki page on Wallet Import Format documents the exact steps.

Here is what a WIF actually contains, in order:

• Version byte (1 byte): 0x80 for mainnet, 0xef for testnet. This is what makes the string readable at a glance.
• Private key (32 bytes): the raw 256-bit number itself.
• Compression flag (1 byte, optional): 0x01 if the key corresponds to a compressed public key. If the key is uncompressed, this byte is left out entirely.
• Checksum (4 bytes): the first four bytes of a double SHA-256 hash of everything above.

All of that gets run through Base58, and the result is the familiar WIF string. The version byte is why you can read the type straight from the first character. A mainnet uncompressed key starts with 5. A mainnet compressed key starts with K or L. Testnet keys start with 9 or c.

Compressed vs Uncompressed WIF, and Why the Address Changes

This is the part that trips people up, so it is worth slowing down. The same private key can produce two different Bitcoin addresses, and the compression flag is the reason.

A private key derives a public key through elliptic curve math. That public key comes in two forms:

• Uncompressed: 65 bytes, written as a 04 prefix followed by the full X and Y coordinates.
• Compressed: 33 bytes, written as a 02 or 03 prefix followed by only the X coordinate. The Y coordinate is recovered from the curve equation, so it does not need to be stored.

Both forms describe the same point on the curve, but they are different byte sequences. A Bitcoin address is a hash of the public key, and hashing two different byte sequences gives two different results. So the uncompressed public key hashes to one address, and the compressed public key hashes to another.

The 0x01 byte inside a compressed WIF is what signals a converter to build the 33-byte public key. Drop that byte and the same private key produces the 65-byte version and a completely different address. If you ever import a key and the balance you expected is missing, a compression mismatch is one of the first things to check. Modern wallets default to compressed keys, but older or imported keys may not.

Address format then adds another layer. The hash can be encoded as a legacy address, a P2SH address, a SegWit address, or a Taproot address, each with its own prefix and rules. We cover that split in detail in our guide to Bitcoin address types from legacy to Taproot.

Why a WIF to Address Conversion Must Happen Offline

A private key is the whole of your control over funds. Anyone who reads it can spend everything the key holds, instantly and irreversibly. That single fact governs how you should handle a WIF to address conversion.

The danger with an online converter is not always obvious. A page can look clean, load fast, and even show a correct-looking address, while a script quietly ships your key to a server the moment you paste it. There is no way to audit what a remote page does with your input after you hit convert. A separate risk lives on your own machine: clipboard-hijacking malware watches for anything that looks like a key or an address and swaps it for the attacker's, so even a copy-paste step can betray you.

The scale of the problem is real. Billions of dollars in crypto are stolen every year, and wallet compromise and phishing account for a large share of it. Key exposure is the common thread through most of those losses.

The defense is simple. Do the conversion on a device with no network connection, ideally one that has never held your funded keys. Air-gapping removes the exfiltration path entirely, because there is no route out even if something on the device tries to send your key somewhere. This is the same reasoning behind cold storage: keep the secret away from anything connected.

QbyteLab built the Bitcoin Research Tool with an offline HEX, WIF, and address converter for exactly this reason. The conversion runs on your phone with no server round trip, so the key never leaves the device. It is a research and study tool, so you can practice with test keys and understand the mechanics without putting real funds in front of a web page.

A Worked Example With a Test Key

To make this concrete, here is a widely documented test key. It holds no funds and appears in public Bitcoin documentation, so it is safe to study. Never do this with a key that controls real coins on any device that is not fully offline.

Start with this raw private key in hexadecimal:

0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D

That same 32-byte number encodes into two different WIF strings depending on the compression flag:

• Uncompressed WIF: 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ
• Compressed WIF: KwdMAjGmerYanjeui5SHS7JkmpZvVipYvB2LJGU1ZxJwYvP98617

Notice the first character. The uncompressed WIF starts with 5, and the compressed one starts with K, exactly as the version-byte rule predicts.

Now the reason all of this matters. Convert each WIF and you get two different legacy addresses from the one private key:

• Address from uncompressed key: 1GAehh7TsJAHuUAeKZcXf5CnwuGuGgyX2S
• Address from compressed key: 1LoVGDgRs9hTfTNJNuXKSpywcbdvwRXpmK

Same secret, two addresses, because the compressed and uncompressed public keys are different byte sequences that hash to different results. If you follow along in an offline converter, you should reproduce these exact values. If you do not, either the key was mistyped or the tool is applying the wrong compression setting.

Once you have an address, the next research step is usually to read its history on-chain. You can see how to do that in our walkthrough on reading any address's full on-chain history, which pairs naturally with converting keys during study.

Putting It Into Practice Safely

A few habits keep this work clean:

• Verify the checksum, not just the look. A valid-looking WIF with a broken checksum will fail decoding, which is the point. Trust the checksum error rather than eyeballing the string.
• Match the compression flag to the address you expect. If a balance looks wrong after import, test both the compressed and uncompressed derivation.
• Keep test keys and real keys separate in your head. Practice on documented test keys like the one above; treat real keys as if any exposure is permanent, because it is.
• Distrust any page that asks for a private key. A legitimate converter does not need a server, so it does not need to be online.

If you want to turn what you have read into muscle memory, do it where the key stays on your own device. The Bitcoin Research Tool by QbyteLab runs its HEX, WIF, and address converter fully offline, alongside an on-chain explorer and key-space analysis, so you can study the format without ever pasting a key into a website. It is live on the App Store and Google Play, with a one-time Premium unlock and no custody of your funds. Download it, load the test key from this article, and confirm the two addresses for yourself before you ever touch a real one.

Frequently asked questions

What does a WIF to address converter actually do?

It decodes the Base58Check string back to your raw private key, derives the public key, hashes it, and encodes the result as a Bitcoin address. The compression flag inside the WIF decides which address you get.

Why does my compressed WIF give a different address than the uncompressed one?

The compression flag tells the tool to build a 33-byte public key instead of a 65-byte one. Those are mathematically different keys, so they hash to two different addresses even though the private key is identical.

Is it safe to convert a WIF on a website?

No. A private key typed into a live web page can be logged or exfiltrated. Do the conversion on an offline device, ideally one that has never touched your funded keys.

How do I tell if a WIF is compressed or uncompressed?

Check the first character. On mainnet, 5 means uncompressed, while K or L means compressed. Testnet keys start with 9 (uncompressed) or c (compressed).