Can Someone Screenshot Your Ticket QR Code? What Actually Stops a Copy

The short answer: yes, a screenshot of a QR ticket is a perfect copy of that ticket, and no property of the image can stop it. A QR code is not a lock or a signature. It is a way of writing text down so a camera can read it, and a photograph of written-down text reproduces the text.

Which raises the question people actually have. If copying is that easy, why does a screenshot of a concert ticket get turned away at the turnstile, while a screenshot of the code for your local workshop walks straight in? The difference is not in the QR code. It is in what happens after the scan — and once you see where the defence really lives, you know which defence you can build yourself.

Why the QR Code Itself Can Never Stop a Copy

Start with what a QR code is. It is a two-dimensional arrangement of light and dark squares that encodes a string of characters, plus error-correction data so it still reads when part of it is damaged or obscured. That is the whole mechanism. There is no secret component, nothing that degrades with use, and nothing that distinguishes the original symbol from an accurate reproduction of it.

You can test this yourself in about ten seconds. Paste any ticket code into the QR code payload decoder and you will see the entire content of the symbol as plain text. Whatever the scanner at the door receives, you can read too. If that text is all the door checks, then anyone holding a photo of the code holds the same thing the ticket-holder holds.

This is why a whole genre of advice — print it bigger, add a logo, use a fancy frame, raise the error-correction level — has no bearing on copying at all. Those things change how reliably a code scans. They do not change what it says, and what it says is the entire payload.

So Why Doesn't My Concert Ticket Screenshot Work?

Because the big ticketing platforms moved the barcode out of the ticket and into a live connection. The code shown in the app is not a fixed value printed once and carried around; it is regenerated continuously, so the thing you screenshotted stops being the current code very shortly after you capture it. The gate is not comparing your image against a stored picture — it is checking whether the code presented is the one that is valid right now.

That is also why those tickets will not open as a PDF, will not print usefully, and insist you install an app or add a pass to your phone's wallet. The app is not a marketing imposition; it is the component that keeps the barcode current. A ticket that can be emailed as a static image is, by definition, a ticket that can be copied as a static image.

One honest caveat on the numbers. You will see specific refresh intervals quoted widely — every 15 seconds, every 60 seconds, depending on the platform. Those figures come from vendor blog posts and press coverage rather than published platform documentation, and they differ between sources and over time. The mechanism is well established; treat any exact interval as unverified.

What a wallet pass can and cannot change after you have it

The rotating-barcode trick is not magic, and one half of it is documented in public. Apple's own developer documentation for updating a pass already in Wallet describes the sequence precisely, and it is worth knowing because it tells you exactly how much of a ticket is mutable:

1. The pass carries a web service URL and an authentication token. After the pass is installed, the device registers itself with the issuer's server, handing over a device library identifier and a push token.
2. When something about the pass changes, the issuer sends an empty push notification to the registered device. It deliberately carries no detail, because pushes can be lost or coalesced.
3. The device then asks the issuer which of its passes have changed since a given update tag, and receives a list of serial numbers.
4. For each changed serial number, the device fetches the latest version of the pass.

The crucial detail is what that update is allowed to touch. Apple's documentation states that any field can be updated except the serial number and the authentication token. The barcode is not on the excluded list. So a wallet ticket's barcode can legitimately be replaced by its issuer at any time, silently, without you reinstalling anything — and a screenshot you took is a photograph of one frame of something that moves. Which barcode formats a wallet pass can carry is a separate question, and a narrower list than most people expect.

Note what this is not. A rotating ticket barcode is a different mechanism from the "dynamic QR code" sold by marketing platforms, where a fixed code points at a redirect URL whose destination you can edit later. Both get called dynamic; they solve different problems. The static versus dynamic QR codes comparison covers the marketing kind, and whether a QR code can be changed after printing covers the printed case. Neither of those gives you a single-use ticket.

The four kinds of ticket, and whether a screenshot works

The third row is the one that surprises people. Adding a ticket to Apple Wallet or Google Wallet does not, by itself, make it uncopyable. If the pass carries a fixed barcode, a screenshot of that barcode is as good as the pass. Wallet is a delivery mechanism; rotation is a feature the issuer has to implement behind it.

The Defence You Can Actually Build: Redeem Each Code Once

Rotating barcodes need a server, a signing scheme and an app. If you are running a 40-person workshop or a 300-person conference, you are not building that. Fortunately there is a second defence that needs none of it, and it is the one that does the real work at most events.

Let the code be copied, and make the copy useless by only accepting it once. The first person to present a code is admitted; every later presentation of the same code comes back as already used. You have not prevented the copy — you have made it worthless, which is the same outcome and far cheaper to achieve.

This is exactly how a paper raffle ticket works, and it is why cloakroom tickets come in matched pairs. The security is not in the token. It is in the ledger.

Here is that ledger, running in your browser. Load the demo list, then try scanning the same code twice:

Three answers, and each one means something different. Admit: on the list, not used yet. Already used: this exact code has been through, so either it has been copied or the same guest is scanning twice. Not on the list: the code is not in your guest list at all, which is a forgery, a code from a different event, or the wrong list loaded.

The second answer is a prompt to look up, not an accusation. Double scans happen constantly at a busy door — a guest holds the phone up again because they did not hear the beep, or a scanner fires twice. That is why an undo exists. What the check gives you is a reason to glance at the name on the screen and ask the person in front of you whether it is theirs.

If You Are Running the Event

Practical consequences, in rough order of how much they matter:

• Issue one code per guest, not one code per event. A single shared code cannot be reconciled with anything: you will never know who came, and the first copy admits everybody. One code per named guest is the whole foundation — the event check-in QR code generator turns a pasted list into exactly that, and if you need codes in volume for something other than check-in, the bulk QR code generator guide covers the general case.
• Make the codes random, not sequential. If ticket 41 is TKT-00041, then ticket 42 is guessable and so is every other ticket. Random codes mean knowing one tells you nothing about the rest.
• Actually scan at the door. This is the step that gets dropped under time pressure, and dropping it removes the only protection the system had. A door that waves people through on sight of a QR code is a door with no ticketing at all.
• Keep the code-to-name mapping, and keep it private. With random codes, that mapping is the only link between a code and a person. It is also a guest list, which is personal data — for some events the list is more sensitive than anything else involved.
• Put nothing personal in the code itself. Guests show their codes to strangers, leave them on tables and post them online. A code containing a name, email or booking reference leaks all of it to anyone who photographs it. A meaningless random string leaks nothing.
• Decide in advance what the door does on a duplicate. Someone has to own the decision, at the door, in front of a queue. Check a name against ID? Call the organiser? Let them in and note it? Any of these is fine. Not having decided is not.
• Print them big enough. A code that needs three attempts in bad light is how doors back up. The print size calculator gives the size for the distance you are scanning from.

If You Are Holding the Ticket

The same mechanism, from the other side:

• Never post a photo of a ticket where the code is readable. This is the one that costs real people real money. A QR code in a photograph is not a picture of a ticket — for a static ticket, it is the ticket, and anyone who screenshots your post can try to use it before you arrive. Cover the code, or crop it out.
• The same goes for boarding passes. A boarding-pass barcode carries considerably more about you than a ticket code does — name, record locator and flight details among them. What is inside a boarding pass barcode sets out exactly what you would be publishing. Train tickets have their own version of this.
• If your ticket rotates, screenshot it anyway — as a receipt. It will not scan at the gate, but it is still evidence you hold the ticket if the app will not load or your battery dies. Just do not rely on it for entry.
• Buying a "screenshot of a ticket" from a stranger is buying nothing. At best it is a static code that the real holder will use before you. At worst it was never a ticket. If a seller cannot transfer the ticket inside the platform that issued it, there is no transfer happening.
• A code sent to you unexpectedly is a different problem entirely. Copying is about your own ticket being reused; a code someone sends you is about where it sends you. That is covered in how to spot fake QR codes.

Check the Door Before the Door Checks You

The honest summary of all of this: at most events, the ticket is not the security — the scan is. A static code and a door that redeems it once is a system that works. A clever-looking code and nobody scanning is not a system at all.

Which means the thing worth testing before the event is the scan itself. Print a sheet, hand a code to a colleague, and scan it off their phone screen in the actual light of the actual doorway. Phone screens are reflective and glare is the most common reason a code that works on paper stumbles at a door. If you want a view of which scanner apps cope with that well, the 2026 scanner app comparison is a starting point, and the wider guide to QR codes for events covers schedules, networking and sponsor codes alongside check-in.

Frequently Asked Questions

Can someone screenshot my QR code ticket and use it?

If it is a static code, yes — the screenshot encodes the same data, so any scanner reads it identically. Whether it gets them in depends entirely on the door: if each code is only accepted once, the first person through uses it up and the copy fails. If nobody is checking, the copy works as well as the original. The protection is never in the image.

Why won't my concert ticket screenshot scan?

Because the barcode in the app is regenerated continuously rather than fixed, so the code in your screenshot is no longer the valid one by the time you present it. This is deliberate, and it is why those platforms require their app or a wallet pass instead of letting you print a PDF. Keep the screenshot as proof of purchase, but expect to open the app at the gate.

Does adding a ticket to Apple Wallet stop it being copied?

Not on its own. A wallet pass can carry a fixed barcode, and a screenshot of a fixed barcode is just as usable as the pass. What Wallet enables is the option of rotation: Apple's documentation for updating an installed pass says every field except the serial number and the authentication token can be changed by the issuer, the barcode included. Whether your issuer uses that is up to them.

How do I make a QR code that can only be used once?

You cannot make the code itself single-use — that property lives in whatever checks it, not in the symbol. What you do is issue a unique code per guest and keep a record of which codes have been redeemed, so the second presentation is recognised. The event check-in QR code generator does both halves in your browser: unique codes out, duplicate detection at the door.

Is a rotating ticket barcode the same as a dynamic QR code?

No, and conflating them causes real confusion. A marketing "dynamic QR code" is a fixed symbol pointing at a redirect URL whose destination you can edit later — the symbol never changes. A rotating ticket barcode is the opposite: the symbol itself changes, continuously, and there is no redirect involved. Buying a dynamic QR subscription does not give you single-use tickets.

Can I tell from looking at a QR code whether it is a copy?

No. Two codes encoding the same data produce the same pattern, and a screenshot is a faithful reproduction. There is no watermark, no wear and no generation count. The only way to know a code has been used before is to have recorded that it was used, which is what a door check does.

What should I do if a code comes back as already used at my door?

Treat it as a question rather than a verdict, because the innocent explanation is more common than the guilty one: guests often hold their phone up twice, and scanners sometimes fire twice. Check the name the system shows against the person in front of you, and have an undo available for genuine mis-scans. Decide this policy before the event, not in front of a queue.

Should I put the guest's name inside the QR code?

No. Guests show codes to strangers and photograph them, so anything inside the code is effectively public. Encode a meaningless random reference and keep the name in a list you hold privately. The door check can then display the name from your list without the code itself ever having carried it.

Does a longer or more complex code make a ticket harder to forge?

Length helps against guessing, not against copying. A random ten-character code is already impractical to guess, and making it fifty characters does nothing about the screenshot problem, while making the printed symbol denser and slower to scan. Randomness defeats guessing; redemption defeats copying. They are separate jobs and extra length only addresses the first.