WebLN

WebLN is a JavaScript interface to the Bitcoin Lightning Network that lets a web application interact with the user's Lightning wallet through a window.webln provider object. A compatible client — usually a browser extension such as Alby, or a wallet-embedded browser — injects the provider so front-end code can request payments and invoices without the website operating any Lightning backend of its own. Apps built this way are sometimes called LApps, and the pattern will feel familiar to anyone who has used a web-wallet bridge in other ecosystems: the page asks, the wallet decides.

Core methods

After the page calls enable() to request permission, it gains access to a deliberately small API surface: getInfo() returns information about the user's node, sendPayment() asks the wallet to pay a BOLT11 invoice, makeInvoice() requests an invoice so the user can receive a payment, and signMessage() requests a signature over an arbitrary message, which enables login and attestation flows. Every call surfaces a wallet prompt, so the user approves each action explicitly — the page can request a payment, but only the wallet can make one. Extensions typically add spending allowances so that micro-payments to a trusted site can flow without a click per satoshi, which is what makes streaming-money interfaces practical.

A few practical notes for builders. Feature support varies by provider, so well-behaved code detects window.webln, calls enable() lazily at the moment of first need rather than on page load, and degrades gracefully when the object is absent — most visitors will not have a provider installed. Errors are part of the API surface too: users reject prompts, wallets lack inbound liquidity for makeInvoice(), and payments fail mid-route, so every call needs an unhappy path. Community extensions have grown around the core (keysend for spontaneous payments among them), but the four core methods remain the dependable baseline — and nothing about WebLN requires heavy dependencies; a static page with a tip button can speak it in a dozen lines.

Why the trust model matters

WebLN's real contribution is where it puts custody. The website never touches keys, never holds a balance, and never learns more than the invoices it is shown; the wallet — the user's own provider, whether a custodial account or a node in their closet — holds the keys and confirms every action. For a sovereign Bitcoiner this is the correct shape for web money: the browser becomes a payment surface, not a payment custodian. It removes the copy-paste friction of moving invoices between tab and wallet while adding nothing to what the site can take from you. The same signature capability powers password-free authentication, closing the loop between paying and identifying without a platform in the middle.

Where it fits in the Lightning web stack

WebLN is complementary to the LNURL family rather than competing with it: a well-built site presents a one-click WebLN flow to extension users and falls back to an LNURL QR code for everyone else. For receiving over a reusable, human-readable identifier rather than a raw invoice, see Lightning Address; for the emerging pattern of wallets connecting to applications over Nostr relays — which extends the same ask-the-wallet model beyond the browser — see Nostr Wallet Connect. Together these specs are converging on the same principle from different angles: applications request, wallets authorize, users hold the keys.

D-Central documents WebLN for builders wiring Lightning into web experiences — tip buttons, paywalled content, machine dashboards that settle in sats. It is a small spec, easily implemented in an afternoon, and that smallness is the point: the least a website needs to ask, and not one method more.