The standardized bitcoin: URI format (bitcoin:address?amount=0.5&label=...) that lets QR codes open a wallet with the recipient address and payment amount pre-filled.
BIP-21 defines the bitcoin: URI scheme — the standard way to express a Bitcoin payment request as a clickable link or a scannable QR code. A BIP-21 URI looks like this:
bitcoin:bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh?amount=0.0025&label=Example%20Store&message=Order%201234
When a wallet app scans a QR code containing this URI, it opens a payment screen with the recipient address, the amount, and the label already filled in; the user only confirms and signs. Without BIP-21, every wallet would invent its own QR payload format and codes would not be interoperable.
URI anatomy
The scheme is bitcoin:, followed directly by the recipient address (no double slash — bitcoin:address, not bitcoin://address). Optional query parameters follow the standard ?key=value&key=value form: amount denominated in BTC as a decimal number (0.0025, not satoshis), label for the recipient name shown in the wallet, and message for the payment reference. Unknown parameters must be ignored by wallets, and a recognized-but-required parameter can be prefixed with req- to signal that wallets unable to process it must refuse the payment rather than silently dropping it.
Why the address stays human-readable in the code
A core design decision in BIP-21 is that the QR code contains the actual address, not a redirect or lookup key. The payer's wallet can validate the address checksum (bech32 for bc1q... addresses, base58check for legacy formats) entirely offline before any funds move. This matters for security: a static BIP-21 QR code printed on an invoice or donation placard needs no server, cannot be rerouted by compromising a redirect service, and remains valid indefinitely. The trade-off is address reuse — a static donation address links all incoming payments on the public blockchain, which is why many merchants generate a fresh BIP-21 URI per invoice.
Amount handling and precision
The amount parameter is expressed in BTC with up to 8 decimal places. Wallets convert to satoshis internally and must handle the decimal precisely — floating-point rounding bugs here would literally cost money, so implementations parse the amount as a decimal string. If amount is omitted, the wallet opens with the address pre-filled and lets the user enter the amount manually, which is the pattern used for donation codes.
QR-specific best practices
BIP-21 URIs are short enough to encode statically at low QR versions: even with label and message, they typically fit in Version 3–4 at Error Correction Level M. Use bech32 (bc1q...) addresses — they are all-lowercase, which packs efficiently in alphanumeric mode, and their checksums catch transcription errors. Always test the scan against at least two independent wallets before printing, and never place a Bitcoin QR code behind a URL shortener: the redirect would hide the address from the payer's verification and add a trusted third party to a trustless payment.
Diagram description: Annotated BIP-21 URI with scheme, address, amount, label, and message segments labeled, and arrows showing how a wallet maps each segment onto its payment confirmation screen.