Lightning Invoice Decoder (BOLT 11)

How it works

A BOLT 11 Lightning invoice is a compact, self-contained payment request. It bundles together everything a payer needs — the amount, the recipient’s payment hash, an optional description, the network, and an expiry timestamp — encoded as a single Bech32 string. This decoder unpacks that string in your browser using the same parsing logic that Lightning wallets use. No payment is initiated, and no data is sent to any server.

BOLT 11 structure

Every BOLT 11 invoice begins with a human-readable part (HRP) followed by the separator 1 and a data section encoded in Bech32. The HRP signals the network and the amount:

• lnbc — Bitcoin mainnet
• lntb — Bitcoin testnet
• lnbcrt — Bitcoin regtest (local development)

After the network prefix comes an optional amount field. The amount is expressed in Bitcoin with a multiplier suffix: m (milli, 0.001 BTC), u (micro, 0.000001 BTC), n (nano, 0.000000001 BTC), or p (pico, 0.000000000001 BTC). Internally, amounts are stored in millisatoshis — 1/1000 of a satoshi — which is why Lightning can route payments with sub-satoshi precision even though the base-layer blockchain only records whole satoshis.

If no amount is present in the invoice, the payer can send any amount. These are called “zero-amount invoices” and are sometimes used for tip jars or pay-what-you-want schemes.

The data section

After the Bech32 separator, the invoice contains a series of tagged fields:

• Payment hash (tag p): A 32-byte SHA-256 hash of the payment preimage. The recipient holds the preimage and reveals it when payment arrives, acting as cryptographic proof of payment. This is the most critical field — it uniquely identifies the payment and prevents double-spending.
• Description (tag d): A short UTF-8 string describing the purpose of the payment. Wallets show this to the payer before confirming. Alternatively, a description hash (tag h) can be used for longer descriptions — only the hash is encoded in the invoice itself.
• Expiry (tag x): How many seconds after the invoice creation timestamp the invoice is valid. The default if omitted is 3600 seconds (one hour), per the BOLT 11 specification. After expiry, the recipient’s node may refuse to accept the payment.
• Timestamp: The Unix timestamp when the invoice was created, encoded in the data section. Combined with the expiry field, this gives you the absolute expiry time.
• Routing hints (tag r): Optional private channel hints that help the payer find a route to the recipient even when the recipient’s node has no public channels.

The entire data section is signed with the recipient’s node private key. The decoder verifies this signature as part of parsing — an invoice with an invalid signature is rejected.

Amount precision

One of Lightning’s most distinctive properties is millisatoshi precision. While the Bitcoin base layer cannot settle amounts smaller than one satoshi, Lightning’s internal accounting uses millisatoshis (msat) throughout. This means a Lightning node can forward a payment of, say, 1 msat — equivalent to one one-thousandth of a satoshi, which at current prices is a tiny fraction of a cent. Routing fees are also expressed in millisatoshis, so a node can charge 0.1% of a 1-sat payment as a fee even though that fee would be less than one satoshi.

This decoder shows the amount in both satoshis (rounded down from millisatoshis) and in BTC, so you can quickly check the invoice amount at a glance without mental arithmetic.

Expiry semantics

Lightning invoices are time-limited for a reason. The recipient’s Lightning node must hold the payment preimage in memory, ready to release it when the payment arrives. If invoices never expired, nodes would accumulate indefinitely many outstanding payment commitments. The standard default of 3600 seconds (one hour) gives the payer sufficient time to act without placing an unbounded burden on the recipient. Some services issue shorter invoices (60–300 seconds) for point-of-sale scenarios. This decoder shows the remaining time in minutes so you can see at a glance whether an invoice is still actionable.

FAQ

Why doesn’t my LNURL decode?

LNURL is a different protocol. An LNURL is a Bech32-encoded HTTPS URL that your wallet fetches to retrieve a BOLT 11 invoice. The URL itself is not an invoice — it is a pointer to where an invoice can be obtained. Lightning addresses in the user@domain.com format are LNURL-pay shorthand. Neither format can be decoded here; only fully formed BOLT 11 invoices that begin with lnbc (or lntb/lnbcrt for test networks) are supported.

What does the “s” prefix mean in some invoice strings?

The s you may sometimes see in invoice strings is part of the tagged field encoding within the Bech32 data, not part of the human-readable prefix. The human-readable prefix always starts with ln. If you see something like lnbc10u1p…, that is a 10-microBTC invoice on mainnet. The characters after the separator are pure Bech32 data and not intended to be human-readable directly.

Why is the default expiry 3600 seconds?

The BOLT 11 specification (originally authored by Rusty Russell) chose 3600 seconds as the default because it is long enough that most payments will either succeed or fail within that window, but short enough that recipient nodes are not burdened with stale commitments indefinitely. Wallets and payment processors are free to set shorter or longer expiry times, but 3600 is what the spec mandates when the expiry field is absent.

Can I use this to pay an invoice?

No. This is a read-only decoder. It inspects the invoice structure and extracts the encoded fields. To actually pay a Lightning invoice you need a Lightning-enabled wallet such as Phoenix, Breez, Mutiny, or a self-hosted node running LND or Core Lightning.

Is the payment hash the same as the payment preimage?

No. The payment hash is the SHA-256 hash of the payment preimage. The recipient holds the preimage in secret. When a payment arrives along a route, the recipient releases the preimage, and each hop in the route uses it to settle its outgoing HTLC. The payment hash is what appears in the invoice and what payers and intermediate nodes can see. The preimage is only revealed at the moment of settlement and serves as the unforgeable receipt.