xpub Inspector — инспектор xpub

What an extended public key is

BIP-32 hierarchical deterministic wallets derive every key from one seed along paths such as m/84'/0'/0'/0/5. An extended key is a key at one point of that tree together with its 32-byte chain code, the extra entropy that makes derivation possible. The public half — the xpub — is 78 bytes in base58check: four version bytes, the depth, the parent's fingerprint, the child number, the chain code and the compressed secp256k1 public key.

From an xpub anyone can compute every non-hardened child public key, and so every address below it: an account xpub at m/84'/0'/0' yields all receive addresses …/0/i and all change addresses …/1/i of that account. It cannot compute a private key, and it cannot follow a hardened step (' or h), which mixes in the parent's private key. That is why watch-only wallets, accounting tools and multisig coordinators are given xpubs, and why an extended private key (xprv) or a seed phrase must never be pasted anywhere — this page refuses both before anything is parsed.

xpub, ypub, zpub and their siblings

BIP-32 defines only the version bytes behind xpub and tpub, which do not say which kind of address the wallet uses. SLIP-132 registered more versions so that the prefix carries the script type: ypub/upub for nested SegWit (P2SH-P2WPKH, BIP-49), zpub/vpub for native SegWit (P2WPKH, BIP-84), and Ypub/Zpub for multisig cosigners (BIP-48). Taproot accounts (BIP-86) use the plain xpub, which is why the inspector shows all four single-key address types for an xpub or tpub and only the matching one for the others.

Converting between prefixes changes only those four version bytes: the key, the chain code and the addresses stay the same. The inspector re-encodes the key under every version of its network, which helps when one wallet exports a zpub and another expects an xpub. A multisig cosigner key derives no address on its own — every cosigner's key is needed — so none is shown for it.

What is checked

The base58check checksum, the 78-byte length and the version are checked first; a private version, or key data that starts with 0x00 (the marker of a private key) under a public version, is refused. The public key must be a point on secp256k1, and a depth-0 (master) key must have a zero parent fingerprint and child number — the invalid keys of the BIP-32 test vectors fail exactly these rules. The inspector then notes what is unusual: a master key being shared (wallets normally share account keys at depth 3), an account-depth key whose child number is not hardened, or an ambiguous xpub prefix.

Derived addresses

Addresses are derived at <chain>/<index> below the key, the BIP-44 layout every mainstream wallet uses: chain 0 for receiving, chain 1 for change. Up to 100 indexes at a time can be listed from any starting index. If the wallet shows other addresses, the key is not at account depth, or the wallet uses another address type or path — the depth and child number above tell which.

Output descriptors

Modern wallets (Bitcoin Core, Sparrow, hardware wallets) describe an account with an output descriptor, such as wpkh([73c5da0a/84h/0h/0h]xpub…/0/*)#checksum. The inspector builds the receive, change and multipath (<0;1>) descriptors for each address type the key allows, with the BIP-380 checksum. Given the master fingerprint and the account path from the wallet, it adds the key origin in brackets, which a hardware wallet needs to recognise its own keys when signing a PSBT.

Sharing an xpub

An xpub cannot spend, but it is not harmless: anyone holding it can list every address of the account, past and future, and follow its balance and payments. Share it with a watch-only wallet you trust, not on a public page. This page decodes everything locally and sends nothing; a share link carries the key in the URL fragment, which never reaches a server, and the page warns before copying one. To check a transaction that spends from these addresses, use the PSBT inspector.