A BOLT11 Lightning invoice is an encoded payment request, not an encrypted private message. Someone with its complete text or readable QR code may decode a description, payment amount and other fields. Exactly what appears depends on the invoice. Treat an invoice as something intended for the payer and the receiving service, rather than a harmless string to publish with a support question.
Start with the description you actually shared
A wallet might display a short caption while keeping a much longer payment request behind its copy button. That caption can be an invoice description or a separate local note. Before posting either, establish which record it belongs to. A private label you added after paying does not rewrite an invoice that was already sent to someone else.
The BOLT11 specification defines a plain-text description field and an alternative description-hash field. A description carried directly in the invoice is readable after decoding. The alternative commits to a description supplied through another mechanism. It is not a promise that nobody has the underlying text or can associate it with the request.
For example, an invoice caption might contain a customer name, an email address or a detailed order reference. Those details are not needed merely to ask why a wallet shows an expired request. When creating an invoice, use the information the transaction genuinely needs and keep unrelated personal notes separately. Follow any recordkeeping requirements that apply; reducing unnecessary disclosure does not mean falsifying the purpose.
Read the fields without assigning them extra meaning
| Decoded item | What it can tell the reader | What it does not establish |
|---|---|---|
| Description | Text included by the issuer, if that form is used | That the text is confidential or independently verified |
| Description hash | A commitment to separately supplied description data | An encrypted copy of the description |
| Amount | The requested amount, when specified | That the requested amount was paid |
| Timestamp and expiry | When the request was created and its validity period | The actual settlement time |
| Signer or destination information | A public-key reference associated with the request | The legal identity of an individual |
| Route hints, if included | Additional routing information | The complete sender route or channel balances |
| Payment hash | A reference associated with the requested payment | Settlement merely because the hash exists |
The LND decoder reference distinguishes these fields. For ordinary non-blinded requests, the signer destination is the payee node public key; newer blinded-path cases require different interpretation. Avoid turning a decoder's technical destination label into a claim about a named person. A service can also manage the receiving infrastructure for its customers.
An amountless request is another reason to avoid reading a screenshot as a receipt. The payer may choose an amount later. Similarly, an expiry field describes the payment request's validity, not how long somebody must wait before funds appear. A decoder can reveal an old request perfectly well without proving that anybody ever attempted to pay it.
A QR code and a hash solve different problems
Rendering the invoice as a QR image changes how someone copies it. It does not make the encoded fields secret. Cropping a visible caption while leaving a scannable QR code can therefore leave the original description accessible. If the aim is to show an error message, crop the payment request itself as well, or reproduce the error text without an invoice attached.
A description hash is different from plain text, but calling it encrypted is misleading. The associated description can arrive with a payment flow, remain in a merchant record or be shared in the same conversation. Consider the whole bundle you are publishing: invoice, order page, chat caption and file name. A single field cannot undo information disclosed elsewhere in that bundle.
Likewise, route hints are not a transcript of a completed payment. They help with routing to a receiver; they do not reveal every path a sender considered or establish the balance of each channel. State what the record actually contains. The Bitcoin Design payment-format guide is useful when distinguishing invoice formats rather than assuming every Lightning request has identical fields.
Prepare a support record with a clear sharing boundary
- Identify the request format and the exact wallet problem. This article concerns BOLT11; do not apply its full field list automatically to BOLT12 offers or Lightning addresses.
- Inspect the invoice in a trusted wallet or decoder whose data handling you understand. Check whether the tool processes input locally or sends it to a server before pasting a live request.
- Separate the original invoice from the wallet's payment result and from your own notes. Keep the originals privately so a cropped screenshot does not become your only record.
- Send the support team the relevant error, wallet version, time and request identifier through its official channel. Provide the full invoice only when needed for that investigation.
- For a public question, remove the invoice string and QR code as well as unrelated personal captions. A redacted example can explain the symptom without exposing a live payment request.
You can use the Lightning invoice decoder as a field-reading aid after considering what you are comfortable entering. This is not a claim about its processing architecture or a guarantee that decoding authenticates a recipient. If the question is which payment format a service accepts, consult Lightning invoices versus Bitcoin addresses before sending anything.
Keep a useful record without making it a public identity file
Imagine a fictional request described as Order Orchard-41, with a wallet note containing a customer's email. The invoice and the note disclose different information. If you post the invoice to explain a parsing error, removing the email from the note does not remove Orchard-41 from the invoice. If that order reference links to a public page with customer details, the combined disclosure is larger still. None of those observations proves that the payment settled.
Keep settlement evidence in the paying or receiving wallet and distinguish it from the request. If a service asks you to demonstrate payment, follow its evidence requirements through the official support channel rather than publishing a full payment history. A public invoice does not automatically reveal the payer's identity, and the absence of a name does not guarantee that other records cannot connect the request to someone.
For a no-account swap, use the actual order instructions to establish the supported network and destination format. Do not assume that a Bitcoin option accepts a Lightning invoice. The practical privacy decision is which information each recipient needs: a payer needs a usable request, support needs diagnostic evidence, and a public discussion usually needs far less.
FAQ
What can a Lightning invoice decoder reveal?
Depending on the request, it can show a description, amount, timestamp, expiry and routing-related fields. Decoding reads the request; it does not prove that a payment settled or identify the legal owner of a node.
Is a Lightning invoice description hidden inside its QR code?
A readable QR code carries the request and does not encrypt its fields. A plain description can therefore remain available even if you crop the wallet's visible caption from a screenshot.
Does a Lightning wallet note change the invoice description?
A separate local note does not rewrite a previously shared invoice. Check which text belongs to the encoded request and which belongs only to the wallet's own records before sharing either.