LNURL decoder

What LNURL actually is

LNURL is a family of protocols that puts a url where a Lightning interaction begins. Instead of copying a fresh invoice for every payment, you scan or click something that points your wallet at a web endpoint, and the wallet takes it from there. The lnurl1 string everyone recognizes is nothing more exotic than that url, bech32 encoded so it can survive QR codes and copy paste.

The most common flavor is LNURL-pay, which lets a wallet request an invoice for an amount within limits the receiver publishes. There is also LNURL-withdraw, where the roles flip and the endpoint offers to pay you, and login and channel variants.

Lightning addresses are LNURL in disguise

An address like tips@example.com is a naming convention on top of LNURL-pay: the wallet turns it into a request to example.com's /.well-known/lnurlp/tips endpoint and proceeds exactly as if it had scanned an lnurl1 string. This is why the address format took over for tipping and zaps on Nostr; it is memorable, printable and fits in a profile field.

The decoder accepts both forms. It shows you the plain https url, and when the endpoint allows browser requests, fetches its parameters: minimum and maximum sendable amount, the description the receiver attaches, and whether it advertises Nostr zap support.

Why decode before you pay

The whole trust model of LNURL is the domain behind the url. A QR code on a poster or a link in a DM can point anywhere, and once decoded, the domain either matches who claims to be receiving or it does not. Ten seconds of looking at the real url is the cheapest scam check in Lightning.

Decoding is also the fast way to debug a failing payment. If the endpoint is unreachable or its limits exclude your amount, the decoder shows it plainly, instead of a wallet spinner.

A detail worth knowing: an LNURL endpoint can change its parameters at any time, because they live on a web server, not in the string you decoded. That flexibility is the feature, and it is also why the decoded domain is the one constant you can anchor trust to across payments.

The same logic applies in reverse when you publish your own address: whoever controls the domain controls where your incoming sats go, so keep the domain renewed and its endpoint monitored like the payment infrastructure it is.