A QR code moves the trust decision onto a different screen
Physical placement, destination previews and payment pages supply different evidence. A QR code should simplify navigation without becoming the only proof of authority.
A QR code can make a physical object feel connected to an official digital process. It is on the parking meter, the café table, the conference badge or the letter from a familiar organization. You raise a phone, see a destination and continue.
The code itself does not know whether its placement is legitimate. It carries data, often a web address. The trust decision belongs to the person and the surrounding system.
That decision is unusually easy to compress. The physical setting suggests authority, the phone takes over the interaction, and the destination may ask for payment or sign-in before the user has independently connected the two. The risk is not the square pattern by itself. It is the unexamined transfer of trust from place to destination.
What changes when you scan
You trust the object or place where the code appears.
Your phone opens data supplied by whoever controls the code.
A new page may request money, credentials or permissions.
These are three separate stages. A code mounted on an official-looking sign does not automatically make its destination official. A page reached from that code does not automatically have authority to request payment.
Scanning also moves attention to a different device. A desktop warning, workplace browsing policy or surrounding document context may no longer be visible. The user now has a small screen and a task to complete.
That does not make QR codes inherently unsafe. It means the interface should preserve the information needed to verify the destination rather than relying on the code’s convenience alone.
The public warnings behind the concern
The FTC’s QR-code warning describes deceptive codes used to direct people toward harmful links and requests. A 2025 New York City Department of Transportation advisory provides a concrete example involving unauthorized QR-code stickers on parking meters.
The city example is local and dated. It does not establish the payment design of every parking authority or prove that any particular code you encounter is fraudulent.
The general design lesson is our inference: when an easily replaced physical marker controls a sensitive digital destination, users need an independent way to identify the legitimate route.
Placement borrows authority
People reasonably use surroundings as evidence. A menu on a restaurant table is more likely to belong to the restaurant than a random leaflet on the pavement. A payment instruction on a meter appears connected to the authority operating it.
The problem is that surface placement can be changed without changing the underlying organization. A sticker can sit over another label, and a printed notice can be introduced into a space where people expect official instructions.
Visual inspection may reveal an overlay or an inconsistent sign, but the absence of an obvious alteration is not proof. Good printing and neat placement are inexpensive signals.
This is why a strong verification method should not depend entirely on spotting a crooked sticker. The relevant operator should be identifiable through a separate, established source.
A preview is information, not a verdict
Many scanning interfaces show a destination before opening it. That preview is useful. It can reveal a surprising domain or an action unrelated to the stated task.
However, recognizing a familiar word in a web address is not the same as verifying the organization controlling it. Shortened links and redirects may also make the final destination less obvious.
Do not teach users that the presence of HTTPS alone resolves the question. An encrypted connection protects communication with the site reached; it does not prove that the site is the intended merchant, employer or public authority.
For sensitive actions, use the operator’s known app, an independently obtained website or an established account route when uncertainty remains. The convenience of scanning should not be the only available path.
The trust-boundary map
| Stage | Evidence available | What still needs checking |
|---|---|---|
| Code on a physical object | Location, printed context, visible placement | Who placed or controls the code |
| Scanner preview | Encoded destination or action | Whether it belongs to the intended organization |
| Landing page | Branding, address, requested task | Whether the destination and request are authorized |
| Payment or sign-in | Form details and claimed purpose | Whether you should perform this action through this route |
| Confirmation | A page or message saying the action succeeded | Whether the real operator recorded it |
The table explains why a single successful step does not authenticate the whole chain. A convincing confirmation page can exist independently of the service you intended to use.
Our consumer guide to parking QR-payment stickers focuses on the immediate payment decision. This article examines the broader interface problem across different settings.
Scanning is not the same as completing an action
A person who scanned a questionable code may fear that the scan alone exposed every account on the phone. That is not a conclusion supported merely by scanning.
The response should distinguish viewing a preview, opening a page, entering information, granting permissions, downloading software and completing a payment. Those actions have different implications.
Do not turn that distinction into a blanket promise that opening any link is harmless. Device security, browser behavior and the destination matter. Keep software current and obtain appropriate support if something unusual occurred.
The useful starting point is a factual sequence: what did the phone show, what did you approve, and what information or access did you provide? That gives a support team a clearer basis for advice than “I used a QR code.”
Login codes deserve special context
Some legitimate services use QR codes to connect devices or initiate sign-in. In those cases, the action can authorize a session rather than merely open an informational page.
Read the service’s own description of what the scan approves. Confirm that you initiated the process on the device or account you intend to connect. A code sent by another person should not be treated as interchangeable with one generated during your own verified setup.
Our guide to device-code sign-in confusion explores a related issue: a genuine authentication page can still be used to authorize the wrong session when the surrounding request is misunderstood.
The boundary is about the action being authorized, not simply whether the sign-in service itself is real.
What organizations should print beside a code
A useful physical design includes the organization’s name, the purpose of the action and a human-readable alternative route. People should be able to verify or complete the task without relying solely on scanning.
For a sensitive payment, provide clear information about the expected operator and supported payment methods. Avoid training users to accept unexplained extra fees or unexpected account creation as normal.
Inspect publicly accessible signage as part of ordinary operations. The frequency and method depend on the setting, but someone should own the physical asset rather than assuming a printed code remains unchanged indefinitely.
Accessibility matters too. A person without a suitable phone, camera or reliable connection should not be forced into asking a stranger to complete a sensitive transaction on their behalf.
Avoid QR-only security communication
An organization that sends an unexpected security notice containing only a QR code creates a verification problem for its own users. The message may ask the recipient to move from a managed device to a personal phone and then sign in.
Provide an independent route through the user’s known account or application. Explain the requested action in ordinary text. Let the user navigate there without using the embedded code.
This is not a prohibition on QR codes. It is a requirement that the code remain a convenience rather than the sole evidence of authenticity.
The channel-switch trust model offers a useful design test: what authority is being transferred when the user leaves one surface and continues on another, and what independent evidence survives the transfer?
If you find a suspicious code in a public place
Do not scan repeatedly to investigate it. Record the location and notify the responsible operator through independently obtained contact information. If safe and appropriate, a photograph of the sign can help the operator identify the issue.
Avoid removing or altering public equipment yourself. The responsible organization can assess the marker and preserve relevant evidence. Do not publicly repost a live suspicious destination as a curiosity that others may follow.
If you already submitted payment or account information, contact the relevant provider promptly through a trusted route and explain the actual action taken. A report to the venue alone may not address the financial or account exposure.
Keep any transaction reference and a record of the legitimate service you were trying to use.
The design principle
An especially useful review is to cover the code on a printed sign and ask whether a visitor can still identify the organization and complete the task. If the answer is no, the design has made scanning a dependency rather than a convenience. Add an accessible alternative and a way to ask the operator for help before asking visitors to decide whether the marker itself is trustworthy.
When those elements remain separate, scanning can stay convenient without becoming an invisible transfer of authority. The goal is not suspicion of every square on a wall. It is clarity about who is asking you to do what after your phone opens the next screen.
Found a factual error or a source that has changed?
Send a correction →
