# Lightning invoice QR codes — BOLT11, LNURL and the uppercase trick

> A Lightning invoice is a bech32 string beginning lnbc that encodes amount, destination and expiry — often 200 or more characters that nobody could type, which is why Lightning payments travel as QR codes. Encode the invoice in upper case so the QR uses alphanumeric mode and stays noticeably smaller.

Source: https://useqr.app/docs/payments/lightning-invoice-qr · Last reviewed 2026-08-21 · UseQR is free forever, MIT licensed, no signup.

---

## Why Lightning needs QR codes

A BOLT11 Lightning invoice looks like this (heavily truncated):

```
lnbc20m1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygs...
```

It is a bech32-encoded, cryptographically signed blob carrying the amount, the destination
node, a payment hash, routing hints and an expiry — routinely **200+ characters** with no
human-meaningful structure. Bitcoin on-chain addresses are just about transcribable in an
emergency; a Lightning invoice is not, under any circumstances. There is no "read it out
over the phone" fallback, no retyping. The QR code is not a convenience for Lightning —
it is effectively the transport layer for any in-person payment.

Two properties follow from the invoice model and surprise newcomers:

- **Invoices expire.** Every BOLT11 invoice carries an expiry, commonly minutes to an hour.
  A printed BOLT11 invoice is a countdown, not a poster.
- **Invoices are single-use.** Once paid, an invoice is settled; paying it again fails.
  A static printed invoice would break even without the expiry.

## The uppercase trick

Bech32 is case-insensitive, and that has a direct consequence for QR density. QR
[alphanumeric mode](/glossary/encoding-mode) packs two characters into 11 bits (**5.5 bits
per character**) but its 45-character set includes only *upper-case* letters; any lower-case
character forces byte mode at **8 bits per character**.

So encode the invoice as `LNBC...` rather than `lnbc...` and the bit stream shrinks by
roughly a third — visibly fewer modules, bigger modules at the same printed size, easier
scanning at [screen or terminal distance](/docs/spec/why-longer-urls-make-denser-codes).
Wallets accept either case. The same trick applies to bech32 on-chain addresses in
[bitcoin: URIs](/glossary/bip21). If you generate invoices programmatically, uppercase
before encoding and [verify the result decodes](/docs/developers/why-verify-that-your-qr-code-decodes).

## LNURL and Lightning addresses — the static-QR answer

Since a raw invoice cannot be printed durably, the ecosystem built indirection layers:

- **LNURL-pay** encodes a URL; the wallet fetches it and receives a *fresh invoice* for each
  payment. That makes a permanent printed code possible — the tip jar, the donation sticker,
  the market-stall sign — with the expiry problem handled per scan. The printed code is
  static; the invoices behind it are not.
- **Lightning addresses** (`name@domain`, email-shaped) are a human-readable identifier
  resolved via the same machinery, and are what most tipping profiles print alongside or
  instead of a code.

The honest caveat: BOLT11 is universal — every Lightning wallet pays a valid invoice —
while **LNURL support varies by wallet**. A printed LNURL code excludes users of wallets
that never implemented it. For a public tip jar, print the Lightning address as text next
to the code, the same
[identifier-as-text fallback](/docs/payments/qr-payment-standards-compared) every payment
scheme benefits from.

## Practical deployment

For a screen at a till, show the BOLT11 QR at generation time and regenerate per sale —
that is what Lightning point-of-sale tools do. For anything printed, use LNURL-pay or a
Lightning address, sized and tested like any payment code (**≥ 4–5 cm** at counter
distance, [quiet zone](/glossary/quiet-zone) intact). And because this is still a
cryptocurrency payment — irreversible, software-dependent — the
[crypto QR safety rules](/docs/payments/crypto-qr-code-safety) apply in full: test with a
small payment first, from a different wallet than the one that generated the code.

## FAQ

### What is in a Lightning invoice QR code?
A BOLT11 invoice — a signed bech32 string beginning lnbc (mainnet) encoding amount,
destination, payment hash, routing hints and expiry. The QR simply carries that string,
which is far too long to type.

### Why should Lightning invoices be uppercase in a QR code?
Bech32 is case-insensitive, and QR alphanumeric mode — 5.5 bits per character instead of
byte mode's 8 — only covers upper-case letters. Uppercasing cuts the bit stream by roughly a
third, producing a smaller, easier-scanning code.

### Can I print a Lightning QR code on a poster?
Not a raw invoice — it expires within minutes to hours and dies permanently when first paid.
Print an LNURL-pay code or a Lightning address instead, which hand each payer a fresh
invoice at scan time.

### Do all wallets support LNURL?
No. Every Lightning wallet pays BOLT11 invoices, but LNURL support varies by wallet. For
public codes, print the Lightning address as text beside the QR so unsupported-wallet users
still have a path.

## Try it

- https://useqr.app/bitcoin
- https://useqr.app/validate