How Can People Subscribe to Push Notifications by Scanning a QR Code?

A QR code can subscribe people to push notifications without an app install, an email form, or a phone number. The QR code links to a public subscribe page; the visitor taps one button, the browser asks for notification permission, and from then on any message you send to that channel is delivered to their phone as a web push notification. That is the whole loop: print or display the code, people scan it, you send updates from a dashboard, a CLI, an API call, or an AI agent.

This guide explains how subscribe-by-scan works under the hood, where it fits (events, shops, classrooms, status updates, field teams), the honest limits of web push on iPhones and Android, and how to set up a QR channel in a few minutes with Pingwire QR Channels.

Why would you want people to subscribe by scanning a QR code?

The usual ways to reach a group of people each carry friction. Email needs an address, lands in a promotions tab, and is slow. SMS needs a phone number, costs money per message, and in most countries requires consent records and sender registration. A native app needs an install, an app-store listing, and two codebases. A group chat leaks everyone's phone number to everyone else.

A QR subscribe channel sits in a different spot on the trade-off curve:

• Zero personal data collected. A web push subscription is an opaque endpoint URL plus encryption keys. You never learn the subscriber's phone number, email, or name. This makes it a natural fit for privacy-sensitive settings such as schools and clinics, and it lowers your own compliance burden.
• Nothing to install. On Android, the phone's default browser handles the subscription. On iPhone, the visitor adds the page to their Home Screen once (more on that below). Either way there is no app-store step.
• Opt-in by physical presence. Only someone who could see the code, on a poster, a table tent, a slide, or a receipt, can subscribe. That is a useful natural filter for local audiences.
• One-tap unsubscribe. Every notification carries an unsubscribe link, and the subscriber can also revoke the browser permission at any time. Consent is real, not a checkbox nobody read.

The trade-off is reach and durability. Web push depends on the browser and the operating system cooperating, and it is not a substitute for a transactional email or a legally required notice. We cover the limits honestly further down.

How does subscribe-by-scan work end to end?

There are four moving parts. None of them are exotic; they are all web standards that browsers have supported for years.

1. The QR code encodes a subscribe URL

Each channel gets a public, unguessable subscribe URL such as https://pingwire.dev/s/<token>. The QR image is just that URL rendered as a code. Pingwire generates it as PNG or SVG, optionally with your logo in the middle, and the image is served with long-lived caching keyed to the token version, so re-issuing the token invalidates old prints. If a poster is stolen or a code is shared where you did not intend, you rotate the token and the old code stops working.

2. The subscribe page requests permission

The subscribe page is a small, no-login page. It shows the channel name and description and one button. When the visitor taps it, the page registers a service worker and calls PushManager.subscribe(). The browser shows its own permission prompt. Because the request comes right after a deliberate tap on a page the person chose to open, permission grant rates are far higher than a prompt fired on page load. If you want the mechanics of service workers, VAPID keys, and push services, read our earlier post How does web push actually work?.

3. The subscription is stored against the channel

The subscription object (endpoint URL plus two keys) is posted to a public, rate-limited API and stored as a subscriber row on the channel. There is no account for the visitor. Pingwire keeps a scan counter and a subscriber count so you can see whether the code on the front door is doing anything.

4. Sending fans out to every subscriber

When you send a message to the channel, the server encrypts the payload separately for each subscriber and posts it to their browser vendor's push service. The push service wakes the service worker on the phone, which displays the notification. Sending is one API call, one CLI command, one dashboard form, or one MCP tool call from an AI agent, and the fan-out happens server-side.

Where does a QR notification channel actually make sense?

These are the situations we designed the feature around. Each one has a physical place where a code can live and a real reason to get short, timely updates.

Events and conferences

Print the code on badges and on a slide at the opening session. Send schedule changes ("Room B talk moved to 2:15"), lost-and-found notices, and "the shuttle leaves in 10 minutes." Attendees do not need to hunt for a Slack invite or install an event app they will delete on Monday. Rotate the token after the event so the code on discarded badges goes dead.

Shops, cafés, and markets

A code on the counter or the door: "Scan to hear when the sourdough is out of the oven" or "Get a ping when we open on market days." Because the customer scanned it in the shop, the audience is by definition local. Because there is no phone number, there is no risk of the list turning into a spam liability.

Classrooms and clubs

Teachers, coaches, and club organizers often need a way to say "practice is cancelled, field is flooded" without collecting parents' phone numbers or running a group chat that exposes everyone's contact details. A code on the syllabus or the noticeboard solves that. Parents can unsubscribe at the end of the term with one tap.

Status updates for a small service

If you run a small SaaS or a community server, put the subscribe QR code on your status page or in your onboarding docs. Users who care about incidents can opt in without giving you an email. This pairs naturally with monitoring: an uptime monitor or a heartbeat check can open an incident, and you post the human-readable update to the channel. For a full walkthrough of the monitoring side, see How to get notified when your website goes down.

Field teams and job sites

A code on the site office wall or in the crew's onboarding pack. Contractors come and go; nobody has to maintain a phone list, and a subscriber who leaves the job simply unsubscribes or lets the browser permission lapse.

How do you set up a QR channel?

The steps below use Pingwire. Everything is free at the moment (Pingwire is in free mode, so every account has Pro limits), and the same channel can be driven from the dashboard, the CLI, the REST API, or the MCP connector.

Create the channel

From the dashboard, open QR Channels and create one with a name and a short description. That description is what visitors see on the subscribe page, so write it as a promise: "Short pings when the schedule changes. Nothing else." Optionally upload a logo to be embedded in the code.

From the CLI, the same thing is:

pingwire qr create --name "Summer Market" --desc "Opening-day and weather updates"
pingwire qr image <channel-id> --format svg > market-qr.svg

Print the SVG at whatever size the poster needs; vector output stays sharp on a banner or a receipt.

Send an update

Any of these deliver the same push to every subscriber:

# CLI
pingwire qr send summer-market --title "Market open" --body "Gates open at 9. Bring a bag."

# REST API (Bearer token is a scoped Pingwire API key)
curl -X POST https://pingwire.dev/api/v1/messages \
  -H "Authorization: Bearer pw_live_..." \
  -H "Content-Type: application/json" \
  -d '{"channel":"summer-market","title":"Market open","text":"Gates open at 9. Bring a bag."}'

An AI agent connected through the Pingwire MCP server can call the same send tool, which is handy for scheduled digests or agent-generated status updates. Details are in the MCP docs, and the broader pattern is covered in How can an AI agent send me a push notification?.

Watch the numbers

The channel page shows scans and subscribers. If scans are high and subscribers are low, the problem is on the subscribe page: usually the description does not tell people what they are signing up for, or the code is placed where people scan it out of curiosity rather than intent. If scans are low, the code is in the wrong place or too small.

What are the honest limits of subscribing by QR code?

Web push is good, and it is not magic. Tell your subscribers the truth about these points, and design around them.

iPhone requires adding the page to the Home Screen

Safari on iOS supports web push only for web apps that have been added to the Home Screen (iOS 16.4 and later). A visitor who scans the code in Safari must tap Share, then "Add to Home Screen," then open the icon and subscribe from there. The Pingwire subscribe page detects iOS and shows these steps, but it is an extra 15 seconds and some people will drop off. Android has no such requirement; Chrome and most other browsers subscribe directly from the scanned page.

Notifications can be throttled or expire

Push services and operating systems apply their own delivery rules. A phone in low-power mode, a browser the user has not opened in weeks, or a device that is offline for longer than the message's time-to-live will delay or drop notifications. Web push is well suited to "the room changed" and poorly suited to "your payment failed, act within 24 hours." Send anything with legal or financial weight through a channel that has a delivery record.

The subscription belongs to the browser

If a subscriber clears their browser data, switches phones, or uses a different browser, the subscription is gone and they must scan again. This is a feature for privacy and a limitation for durability. Keep the code up permanently where the audience is, not just on launch day.

It is broadcast, not conversation

Subscribers cannot reply through the push. If you need a two-way channel, that is what Pingwire's chat channels are for; QR channels are deliberately one-to-many.

Practical rules for a channel people do not mute

• Say the cadence up front. "At most two pings a week" on the poster and in the description. Then keep it.
• Lead with the fact. A push shows a short title and a line or two of body on the lock screen. Put the change in the first six words: "Room B moved to 2:15," not "Important schedule update."
• Never send a test to the live channel. Create a private channel, subscribe your own phone, and test there. Nothing burns trust faster than "test test ignore."
• Rotate the token when the context ends. After the event or the term, regenerate the code so stale printed copies stop working, and start fresh next time.
• Include the unsubscribe path in your own copy. Pingwire adds it, but saying "unsubscribe any time from the notification" on the poster reassures people before they scan.

QR channel versus the alternatives, briefly

Method	Data you collect	Install needed	Cost per message	Best for
QR web-push channel	None (opaque endpoint)	None on Android; Home Screen add on iOS	None	Local, low-volume, timely updates
SMS list	Phone numbers	None	Per message	Must-arrive notices, no smartphone assumed
Email list	Email addresses	None	Low	Longer content, records, non-urgent
Group chat app	Everyone's contact details	Yes	None	Two-way discussion in a known group

None of these is universally better. For a small audience that is physically in front of you and wants short, timely, low-frequency updates without handing over personal data, the QR channel is the lightest option that exists. For the standards behind it, the W3C Push API specification and MDN's Push API documentation are the authoritative references.

Ready to try one? Create a channel on the QR Channels page, print the code, and send yourself the first ping.