Lightning decoder
Paste any Lightning Network request and see what is inside it: a Lightning address, an lnurl1 string, a BOLT11 invoice or a BOLT12 offer. The decoder recognizes the format on its own, and everything decodes in your browser.
Four formats, one payment network
Lightning grew its payment formats in layers, and each layer left a string format behind. BOLT11 invoices are the original: a single-use request for a specific payment, carrying the amount, a payment hash and an expiry, signed by the node that wants to be paid. LNURL came next, replacing the single-use invoice with a reusable web endpoint your wallet talks to, and Lightning addresses put a human-readable name on top of LNURL-pay. BOLT12 is the newest layer, building reusable offers into the Lightning protocol itself, with no web server involved.
In practice you meet all four: a shop terminal shows a BOLT11 invoice, a tip jar prints a Lightning address, a Nostr profile carries an LNURL, and a modern node hands out a lno1 offer. This decoder accepts whichever one you paste and shows the fields that matter for that format.
What a BOLT11 invoice carries
A BOLT11 invoice is bech32-encoded data with a signature on the end, and everything a wallet needs sits in its tagged fields: the amount in the prefix, a timestamp, the payment hash that proves settlement, an optional description, and an expiry that defaults to one hour. The decoder lays these out, converts the amount to sats, and tells you plainly when the invoice has already expired, which is the single most common reason a payment fails.
The network is in the prefix too: lnbc is mainnet, lntb testnet, lntbs signet and lnbcrt regtest. If a payment refuses to go through, checking that the invoice is actually for mainnet takes two seconds here.
BOLT12: offers without a web server
A BOLT12 offer (lno1) is what a static Lightning payment code looks like when the protocol itself does the work LNURL delegates to a web server. An offer is reusable, can name an amount in sats or a fiat currency, and the invoice it later produces travels over the Lightning Network itself. That removes the web domain from the trust model entirely, which is the main argument for BOLT12 over LNURL.
The decoder reads the offer's TLV fields: description, issuer, amount, expiry and the issuing node's id. It handles the lnr1 invoice request and lni1 invoice forms too, so you can inspect any stage of a BOLT12 payment.
Why decode before you pay
Every Lightning string is opaque until decoded, and opaque strings are where mistakes and scams live. Decoding shows you the destination behind a Lightning address, the real amount behind an invoice, and whether the thing you were sent has already expired. Ten seconds of reading beats a stuck payment or sats sent to a stranger.
For LNURL and Lightning addresses the decoder also fetches the endpoint's parameters when it allows browser requests: sendable limits, the receiver's description, and whether it advertises Nostr zap support. For BOLT11 and BOLT12, nothing is fetched at all; the string itself contains everything shown.
Put your sats to work
Sats ready to spend? Azzamo Premium takes Lightning payments from one hour to one year of relay time, no account needed.
Get Premium