Bitcoin addresses are not interchangeable labels. Legacy, SegWit, and Taproot formats encode different output rules, and wallet software may support some formats better than others. A reader sending funds across countries or between older services should verify the network, the complete address, and the expected format before signing. This article explains the visible prefixes and the compatibility tradeoffs while avoiding the dangerous assumption that a familiar-looking string proves ownership.

Recognize the common prefixes

Legacy Pay-to-PubKey-Hash addresses usually begin with 1, while Pay-to-Script-Hash addresses often begin with 3. Native SegWit addresses use Bech32 and begin with bc1q; Taproot addresses use Bech32m and begin with bc1p. Prefixes are a useful first check, not a complete validation. Some test networks use different prefixes, and a service can show a label that is not the address type. Copy the address from an official wallet screen and verify it on the same network.

Understand what SegWit changes

SegWit separates witness data from the transaction’s older serialization and changes how virtual size is measured. Native SegWit outputs can reduce fee weight compared with legacy outputs, but the saving depends on the transaction shape and current fee market. A sender’s wallet may support a native address while an old exchange withdrawal system does not. If a platform rejects a bc1 address, read its support documentation rather than changing networks or using a random converter.

Treat Taproot as a script upgrade

Taproot addresses begin with bc1p and can support key-path and script-path spending. Their visible format does not reveal whether a complex policy exists behind an output, and a wallet may hide the script details. Taproot support is now common but not universal. Ask which address types the receiving service accepts, and test a small amount only when the transfer is reversible enough for your situation. Never send a second payment because a stranger claims the first format was “unlocked.”

Verify the full string and network

A checksum can detect many typing errors, but a valid checksum does not identify the intended recipient. Compare the first and last characters on both screens, use the wallet’s QR scanner when appropriate, and confirm the network name. Beware of clipboard malware that replaces a copied address. A hardware wallet display is a useful independent check because it shows the destination that the device will sign, not merely the text supplied by a browser.

Avoid address format myths

A newer prefix does not automatically mean lower fees, stronger privacy, or better recovery. Privacy depends on address reuse, wallet construction, and what an observer can link. Recovery depends on the seed and derivation path, not only on the first character of one address. A service may generate a fresh address for every deposit. Record the purpose and service behind an address instead of treating the string as a permanent account number.

Document a compatibility decision

Before a cross-border payment, write down sender wallet, receiving service, network, address type, expected amount, fee policy, and confirmation requirement. Save the service’s current support page with its date. If the format is unsupported, choose a documented alternative and verify the final address again. This workflow may take longer than clicking the first option, but it creates evidence that can help support staff investigate a mistake without exposing signing secrets.

Operational worksheet

A useful address compatibility worksheet has five fields: sender software and version, receiving service and entity, network, accepted address types, and a test result. Ask the receiving service whether deposits to a fresh address are credited automatically or require a memo, tag, or manual review. Confirm the exact network in both interfaces before copying an address. If a QR code and text string disagree, stop and regenerate the request rather than guessing which one is correct. Preserve the address type in your private notes so a later support case can explain why a transfer used bc1q, bc1p, or a legacy form. When a service changes its supported formats, update the note with an effective date. Address compatibility is an operational detail that can change without changing the Bitcoin protocol itself.