Can you scan a QR code with the same phone that is displaying it?

Not with the camera, because the camera faces away from the screen. There are three ways round it, in order of reliability. Long-press the code in most Android apps and Chrome, and 'Search with Google Lens' or 'Scan QR code' appears. On iPhone, screenshot the code, open it in Photos and tap the Live Text or Lens button, which reads the code out of the saved image. Or, best of all, send a plain clickable link alongside the code so nobody on a phone has to do either.

Why is the QR code in my email not scanning?

Usually because it is not being shown. Outlook and Gmail block remote images from senders that are not in the address book, so the recipient sees an empty box or the alt text where the code should be. After that the common causes are a transparent-background PNG turned into a light-on-dark code by the client's dark mode, and the client scaling the image down below the size the camera can resolve. Send the code as an inline attachment rather than a hotlinked image, export it on a solid white background, set it around 250 to 300 pixels wide, and put the same destination underneath as ordinary clickable text.

What size should a QR code be on screen or in an email?

Use the ten-to-one rule that governs print: the code should be about a tenth of the distance it is read from. A monitor read at arm's length, roughly 50 cm, wants a code about 5 cm across, which is 200 to 250 CSS pixels; export at twice that so it stays sharp on a high-density display. A slide read from the back of a room at 10 m wants a metre, which is why a code on a projected slide is usually decorative rather than scannable. A code on a phone screen shown to a door scanner needs no minimum at all, because the scanner is 10 cm away.

Guides2026-08-26

Can you scan a QR code from a screen?

Q: Can you scan a QR code from a screen?

Yes. A phone camera reads a code from a laptop, monitor, TV or another phone as readily as from paper, and often better, because a lit screen has more contrast than ink on stock. The three things that stop it are specific to screens: the display auto-dimming or sitting at low brightness, dark mode inverting a code that was exported with a transparent background, and glare from an overhead light or window at the wrong angle. Tilt the screen or the phone about fifteen degrees, raise the brightness, and it reads.

Twenty guides in this cluster end at paper. Half of them then quietly hand the code to a screen instead — emailed to the guest, shown at the door, dropped into a slide — and assume the paper rules carry over. They do not. A screen removes the two problems print spends all its effort on, size and contrast, and replaces them with three that no print guide can see: dark mode, blocked images, and a camera that cannot see the glass it is behind.

The five-minute version

Export the code as a PNG on a solid white background, not transparent, about 600 px square.
Display it at roughly a tenth of the reading distance: about 250 px wide for a monitor at arm’s length.
Put the destination underneath as a plain clickable link. Anyone reading on the device holding the code cannot use the camera.
In email, attach the image inline rather than hotlinking it, and write alt text that names the destination.
Test it the way it will be read: send the mail to yourself, open it in the client your audience uses, in dark mode, and scan it off the glass with a second phone.

What a screen removes, and what it adds

Every print guide here is fighting two things. Size, because ink modules below about 0.4 mm stop resolving, and contrast, because dye spreads into stock and narrows the light gaps. A screen deletes both. It emits its own light, so contrast is better than any paper achieves, and it has no ink to spread, so a module is exactly as wide as it was drawn. This is why a code that fails on a receipt often reads instantly from the same shop’s monitor.

What replaces them is a different class of problem entirely. Paper is passive: what you exported is what the reader sees. A screen is the end of a rendering pipeline — a mail client, a theme, a brightness sensor, a sheet of glass — and every stage of it is entitled to change your image before the camera ever sees it. The failures below are not really about scanning. They are about what happened to the file on the way.

Failure one: dark mode inverts a transparent code

A QR code is specified as dark modules on a light background. Scanners have got good enough that most modern phones will also read the inverse, light on dark, but plenty of hardware will not — door scanners, warehouse guns, older Android cameras. So a code that inverts is a code that works for most of your audience and silently fails for the rest, which is the worst kind of bug to own.

Transparency is the actual defect. A PNG exported with a transparent background has no white in it — it is dark modules and nothing. On a light page the page supplies the white. Switch the client to dark mode and the page supplies black instead, and your code is now dark-on-dark, or gets auto-inverted to light-on-dark by the client’s own colour filter. Export on a solid background and the whole class of problem disappears, because the quiet zone travels inside the file.

The same applies on the web. A code dropped into a page that honours prefers-color-scheme will be inverted by any blanket filter: invert() dark theme. Wrap it in an element with an explicit light background rather than trusting the image to defend itself.

Failure two: the email client never showed it

This is the most common report and the least like a scanning problem, because there is nothing on the glass to scan. Outlook and Gmail block remote images from unknown senders by default. If the code is an <img> pointing at a URL, a large share of recipients see an empty rectangle and a “display images” prompt they will not tap.

Attach it inline (CID) rather than hotlinking. An embedded image travels with the message and is not subject to the remote-image block.
Write alt text that carries the destination. “QR code — check in at example.com/e/48213”. This is also the only version a screen reader can use; a QR code is invisible to assistive technology by construction.
Set explicit width and height on the image. Outlook renders at 96 DPI and will resample an unsized image unpredictably; a 600 px export displayed at a declared 250 px stays crisp and predictable.
Never rely on the code alone. The plain link beneath it costs one line and rescues every recipient reading on the device that holds the code.

Failure three: brightness, glare and the fifteen-degree tilt

A camera reading a screen is reading a mirror as much as an image. A window or a ceiling light reflected across the code wipes out the modules under it, and unlike paper you cannot move into better light — better light is the problem. Tilt either the screen or the phone about fifteen degrees and the reflection leaves the frame. Low brightness and aggressive auto-dimming do the same thing more quietly, especially on a phone that has been idle in someone’s hand at a door; raising brightness to full before presenting a code is the single most useful instruction you can print on a ticket.

Two smaller ones worth knowing. A cracked or heavily matted screen protector scatters enough to break a small code, so size up when the display is a shared kiosk. And polarised sunglasses can black out an LCD entirely at the wrong angle — a genuine cause of “the scanner is broken” on a sunny door.

The one case that genuinely cannot work

The camera is on the back of the phone and the code is on the front. No amount of tuning fixes that, and it is the single most common way an emailed code fails in practice, because most email is read on a phone. The workarounds exist — long-press and “Search with Google Lens” on Android, screenshot then open in Photos on iPhone — but expecting a customer to know them is a design choice, not a solution.

If the recipient reads your message on the device that must act on it, the QR code is decoration and the link is the product. Send both: the code for whoever prints the mail or opens it on a laptop, the link for everyone else. Use the code alone only when the reader and the scanner are certainly two different devices — a ticket at a door, a table card, a poster.

Screens that are not phones

Slides and projectors. Apply the ten-to-one rule honestly. Read from 10 m, a code needs to be about a metre across; at any realistic slide size it is unscannable from the back three quarters of the room. Say the short URL out loud and keep the code for the people at the front.
Digital signage and TVs. These work well, because the viewer walks up. Size for the distance people actually stop at, not the distance they first see it from, and hold the code on screen for at least eight seconds — a carousel that rotates every four defeats anyone still getting their phone out.
Video calls and streams. Compression is the enemy: an encoder allocates bits to faces and motion, and a high-frequency black-and-white grid is exactly what it throws away first. Make it large, keep it still, and leave it up.
Another person’s phone, held out to you. Ask them to raise brightness and hold still. Your camera is fighting their auto-dim, their fingerprints and their case tilt, all at once.

What this settles about renting your codes

Digital delivery looks like the strongest case for a dynamic code, and for one moment it is the weakest. Nothing has been printed, so nothing is stranded: if the destination changes before you send, you regenerate and send. The editability you would be paying a subscription for is a thing you already have for free, right up until the moment you press send.

After that, an email you have already sent is printed matter. You cannot recall it from ten thousand inboxes any more than you can recall a flyer from ten thousand doormats. The screen is not the flexible medium — unsent is the flexible medium, and it lasts exactly until delivery. Which means the honest question is the same one the packaging guide asks: if this destination might really move, encode a redirect on a domain you own, and keep the ability to move it without keeping a subscription.

Before you send the batch

Send one to yourself and open it in the client your audience uses — Outlook desktop and the Gmail app are the two that break things — with dark mode switched on.
Scan that message off the screen with a second phone, and then try to use it on the phone showing it. Both paths must end somewhere sensible.
Check the code appears with images blocked. If it does not, your alt text is the entire message, so read it as if it were.
Confirm the destination one last time from the sent copy, not from your spreadsheet. The mail-merge column can be right while the merge field is wrong, and every recipient gets the same wrong code.
Keep the CSV. If it turns out the batch went out inverted or undersized, the fix is a resend, and the resend needs the file that made it.