8 Clever QR Code Uses You Haven’t Tried Yet (and 3 You Should Avoid)
A practical guide to QR codes in 2026: the 8 most useful non-obvious uses (Wi-Fi sharing, contact cards, restaurant menus, payment, event tickets, two-factor backup, package tracking, and table-top donation), the 3 cases where QR codes are a bad idea, and how to generate a working code in your browser without uploading anything.
QR codes are most useful when the encoded data is too long to type but too short to need an app. The 8 best non-obvious uses: Wi-Fi sharing, contact cards (vCard), restaurant menus, payment links, event tickets, two-factor backup, package tracking, and table-top donations. The 3 cases to avoid: short URLs that could just be links, sensitive data that should not be photographed, and aesthetic-only codes that do nothing functional. The <a href="/qr-code-generator">QR Code Generator</a> on this site creates a working code in your browser for any of these cases, with nothing uploaded.
QR codes are one of those technologies that everyone has on their phone and almost no one uses to its full potential. The default use case is "scan to open a URL" — useful, but a fraction of what the format can do. This post covers the 8 most useful non-obvious uses for QR codes in 2026, the 3 cases where QR codes are a bad idea, and how to generate a working code in your browser without uploading anything.
Why QR codes work in 2026
Three things changed in the last five years that made QR codes practical for everyday use:
The combination is what makes QR codes useful for cases beyond "scan to open a URL". The codes can carry structured data that the phone interprets automatically, and the user does not need an app.
The 8 most useful non-obvious uses
1. Wi-Fi sharing
The Wi-Fi QR code encodes the network name, the password, and the authentication type. The phone scans the code, prompts the user to join the network, and joins. The user does not have to type a long password, do not have to know the network name, and does not have to read the case-sensitive punctuation.
The format is WIFI:T:WPA;S:network-name;P:password;H:false;; (WPA2, with the network name, password, and hidden flag). The QR Code Generator handles this format directly. The use case: print the code on a sticker and put it on the fridge, the office wall, or the guest-room nightstand. Guests can join the network by scanning, without the password being spoken aloud.
For a public venue (a cafe, a hotel, a co-working space), the code is a much better UX than a printed password. The printed password is short (so it is easy to type) and rarely changed; the code can encode a long, frequently-rotated password that no one has to type.
2. Contact cards (vCard)
The vCard QR code encodes a contact card: name, phone, email, address, organization, and any custom fields. The phone scans the code, prompts the user to add the contact, and adds it to the address book. The user does not have to type a single field.
The format is the standard vCard 3.0:
BEGIN:VCARD
VERSION:3.0
FN:Jane Doe
TEL:+15555550100
EMAIL:[email protected]
ORG:Example Co
URL:https://example.com
END:VCARD
The use case: print the code on a business card, a conference badge, or a "contact us" page. The recipient scans and adds the contact without typing a single field. The data is more accurate (no typos) and faster (one scan vs. many typed fields).
The privacy case: the vCard is in plaintext in the QR code. Anyone with a QR decoder can read the contact details. The fix: only share the code with people who need the contact, and rotate the code if it is leaked. For high-volume sharing, the QR Decoder shows what a code contains before you scan.
3. Restaurant menus
The QR-code-as-menu use case exploded during the pandemic and has stuck. The code on the table encodes a URL to the menu (HTML, PDF, or a Google Doc). The user scans, sees the menu, and orders. The restaurant does not have to print menus, can update the menu in real time, and can track which items are ordered most often.
The URL should be short and stable (a custom domain, not a query string that might change). The menu should be mobile-friendly (most scans are on phones). The most common mistake: a menu URL that requires a login. The friction kills the use case.
For a restaurant that does not want a third-party menu service, the right approach is a static HTML page on the restaurant's own domain. The HTML to PDF tool on this site can also generate a PDF menu from the same HTML, for the cases where a paper menu is still useful.
4. Payment links
The payment QR code encodes a payment link: a Venmo link, a PayPal link, a Stripe checkout URL, a Bitcoin address. The phone scans the code, opens the payment app, and prefills the amount (if encoded) and the recipient. The user confirms the payment.
The use case: a freelancer sending a payment request, a small business receiving payment at a market stall, a non-profit receiving donations, a friend splitting a bill. The QR code removes the friction of "open the app, find the recipient, type the amount" and reduces it to "scan and confirm".
The format depends on the payment app. Venmo uses a URL with a recipient and an amount query parameter; PayPal.me uses a similar pattern; Bitcoin uses a URI scheme that includes the address and the amount. The QR Code Generator handles any of these — the encoded data is whatever string you provide, so the format is whatever the payment app expects.
5. Event tickets
The event-ticket QR code encodes a unique ticket ID. The user scans the code at the door, the system validates the ID against the ticket database, and the user is admitted. The use case: concerts, conferences, sports events, movies, flights, transit.
The ticket ID is usually a UUID or a long random string, with a signature to prevent forgery. The check at the door is "does the ID exist in the database, is the event still valid, has the ticket been used before?" A successful check marks the ticket as used and admits the user.
The privacy case: the ticket ID is in plaintext in the code. A screenshot of the code is the same as a copy of the ticket. The mitigation is the one-time-use check (the ticket is invalidated on first scan), which is the same protection as a paper ticket with a torn stub.
6. Two-factor backup
The two-factor backup QR code encodes the TOTP secret for an account. The user generates the code when setting up 2FA, stores it in a safe place (a password manager, a printed paper in a safe), and uses it to recover the 2FA if the phone is lost.
The format is the standard otpauth://totp/... URI that authenticator apps use. The QR Code Generator handles this format directly. The use case: any account where 2FA is required and the user wants a backup in case the phone is unavailable.
The security case: the QR code is the secret. Anyone with the code can generate the 2FA codes. The mitigation: store the code in a secure place (a password manager, an encrypted backup), not in plaintext on the phone or in a screenshot. The same security model as the password itself.
7. Package tracking
The package-tracking QR code encodes a tracking URL. The user scans the code, sees the tracking status, and knows where the package is. The use case: a delivery service that includes a QR code on the shipping label, so the recipient can scan and track without typing a long tracking number.
The URL usually includes the tracking number as a path or query parameter, plus the carrier's domain. The carrier's site looks up the number and shows the status. The same as a printed tracking number, but the user does not have to type it.
For a small business shipping products, the right approach is a QR code on the shipping label that encodes the carrier's tracking URL. Most shipping platforms (ShipStation, EasyPost, Shippo) generate this code automatically.
8. Table-top donation
The donation QR code encodes a payment link to a non-profit. The user scans the code, sees the donation page, and donates. The use case: a non-profit that wants to accept donations at events without handling cash or check.
The code is the same as the payment-link case, but the recipient is the non-profit. The most common pattern is a code on a small card on each table, with a short URL underneath (so the user can type the URL if they do not want to scan). The card is the "donation point of presence" for the event.
The privacy case: donations are usually anonymous by default. The QR code does not change that. The non-profit knows the amount and the time, but not the donor's identity (unless the donor chooses to identify themselves in the payment app).
The 3 cases to avoid
QR codes are not the right tool for every case. The three to avoid:
1. Short URLs that could just be links
If the URL is short enough to type, the QR code is friction for no gain. A user who can type "example.com" is faster than one who opens the camera, points it, and waits for the scan. The QR code is right for long URLs (tracking numbers, deep links, session IDs) and wrong for short ones.
The exception: a print medium where typing is not an option (a billboard, a magazine ad, a business card). In that case, even a short URL is better as a QR code than as a printed string.
2. Sensitive data that should not be photographed
A QR code in plaintext is just a string. Anyone with a decoder can read it. The QR code is wrong for sensitive data (passwords, API keys, personal identifiers) where the expectation is "the user reads it and the code self-destructs".
The exception: a code that is one-time use (a TOTP backup that is invalidated after first use, an event ticket that is invalidated at the door). In that case, the one-time-use check is the security, not the secrecy of the code.
3. Aesthetic-only codes that do nothing functional
A QR code that does not encode anything functional (a logo QR code, a colored QR code, a "scan to see what happens" QR code) is wasted space. The user scans, sees a generic page, and learns not to scan QR codes in this context. The result is reduced trust in the legitimate uses.
The exception: a marketing campaign where the "scan to see what happens" is the entire point (an ARG, a scavenger hunt, a brand experience). In that case, the design intent is clear and the user's expectation is set.
How to generate a working QR code
The whole generation runs in the browser. The data (URL, vCard, Wi-Fi credentials) is in your input field; the code is rendered locally; nothing is sent to a remote server. For sensitive data (a Wi-Fi password, a personal vCard), this is the right setup.
How to verify a code works before shipping
The most common failure mode: a QR code that does not scan. The fix is to verify before printing or publishing:
The QR Decoder on this site reads a code's content. If the decoder reads the same data that was encoded, the code is correct.
How to use the tools together
The workflow for a real use case (a conference badge with a vCard QR code):
All the tools run in the browser. The contact details and the code stay on your device; nothing is uploaded. For a small business or a freelancer who needs to print QR codes regularly, this is the right setup.
A short summary
The decision is rarely hard. The wrong answer is to use a QR code for a case where a link would work, or to put sensitive data in a code that anyone can scan. The right answer is to match the code to the use case, generate it locally, verify it, and ship.