QR code on your event ticket and pass — how to handle it simply

Three seconds. That is how long it takes to let one person in when the QR code on the ticket works as it should. Now multiply that by 200 guests at a conference. At three seconds per person, the entire queue clears in about ten minutes. At three minutes (because codes won't scan, screens have dimmed, someone is looking for a PDF in an email from a month ago), it turns into an hour and frayed nerves at the gate.

This is not about aesthetics. A QR code on an event ticket either streamlines entry or clogs it up so much that people are freezing outside. I will show you how to achieve the first variant. Without expensive ticketing and without any complicated workarounds.

What is this code actually supposed to do

Let's start with a distinction that will save you a lot of pain. A QR code on a ticket can do two things.

It may lead to a page. Ticket view, program, hall map, check-in form. Simply a link embedded in the squares.

Or it may carry a unique identifier. A random string that your system reads and checks in the database to see if this specific ticket has already passed through the gate. This is already full ticketing with validation.

For events of up to a few hundred people, this first variant handles about 90% of situations. Everyone gets one link, the code leads to that link, and you check the surname or number visually at the entrance. No backend. No application. No server that likes to crash exactly on Saturday at 18:00.

One link, one code per person

You are organizing a workshop for 80 people. Before you generate a code from a raw, long address, shorten it. A short link provides a less frequent code, less dense squares, better printing, and a more reliable scan from a crumpled piece of paper or from a screen that someone has dimmed to zero.

In cutty it is one move: you paste the target address, you get a short link, and a QR code is created immediately from this link. You can make the ending branded, so that it looks credible on the ticket, rather than like a random shortener from an advertisement:

https://cutty.dev/warsztat-czerwiec/wejscie

You paste such code into your ticket template (Canva, a document, whatever you have) and print it or send it via email. That's it.

Replaceable goal, or a rescue for the day before

There is one thing you will only appreciate in hindsight. You have printed 200 tickets, and the day before the event, the room changes. Or the registration time. If the code leads directly to the old address, you have 200 pieces of scrap paper.

With a short link, the QR code remains the same, and you only change where it leads. From the panel, in about ten seconds. Printed tickets continue to work, opening the current page instead. The same saves you when an event is rescheduled or when you move the program to another subpage.

What if you really must count entries

Sometimes, one ticket is meant to let in exactly one person and not once more. In that case, you need a unique code for each. The minimum scheme looks like this:

1. You generate a list of random identifiers (evt-a7f3k9, evt-m2x8qp and so on).
2. You attach each one to a separate short link leading to the "ticket valid" view.
3. At the gate, you scan, and the person at the entrance checks off the name on the list.

Full automatic validation, this whole "already used / not yet used" thing, will only be given to you by a dedicated ticketing system. But for an intimate event, a list in a spreadsheet plus a phone scan does the job for zero zlotys. Really.

Four things that kill code at the gateway

QR codes always fail for the same reasons. From experience:

• Print is too small. Do not go lower than approx. 2.5–3 cm per side. The smaller it is, the more the scanner struggles in low light.
• Contrast is too low. Code on a colored background or on a photo is asking for trouble. Black on white. Always.
• Lack of margin. The code needs a white border around it (so-called quiet zone). Pressed right up against the edge of an image can fail to scan.
• Long link. The more characters, the smaller the squares. Shortened address = more readable code. We are back to the first point.

And one more thing, trivial, yet people forget it: test the printed ticket with three different phones before sending anything further. Paper is not a screen. What looks beautiful in the preview can be stubborn on a printout and refuse to scan.

How many actually came

There is another side effect, quite a pleasant one. Since the code leads through a short link, you get a counter as a bonus. You can see how many times the ticket was opened and roughly when. Without building a guest profile, without creating an account for them, without tracking them across the entire internet. cutty keeps this on servers in the EU and does not save the raw IP, which matters when dealing with tickets (where the data of people who attended your concert or training is involved).

This is a real difference compared to plugging in the first available QR generator with ads and an unknown redirection inside. When it comes to tickets, where everything relies on trust, such things matter.

Run this code and replace the link under it in cutty.dev, before you start printing the entire batch. Because fixing something after printing 200 pieces is a completely different conversation.