Event Ticket Template

Point it at one page, not four

The instinct is to give the ticket a QR code for the schedule, another for the map and another for parking. Do not. A ticket is a small surface and three codes at 1.5cm each scan worse than one code at 3cm.

Make one page — the event page you would send someone who asks "what do I need to know?" — and put the schedule, map, door times, parking, bag policy and a phone number on it, in that order. One code, one destination, and it stays legible when the ticket is folded into a pocket.

The same code usually ends up on a screen too — the stage backdrop, the opening slide, the livestream of the keynote — and a screen has its own rules for how big the code has to be and how long it stays up. QR codes on screens covers that surface, including when a link in the chat is the better tool.

Make it dynamic if anything can change

A static code encodes the URL directly into the pattern. Once it is printed, that address is permanent — if the venue changes, the stage times slip or the page moves, every printed ticket is now wrong and there is no fixing it.

A dynamic code encodes a short CreateQRCodes address that redirects. You can re-point it after printing, which is what makes it useful for anything with a rain plan, a schedule that firms up late, or a venue that could move. Dynamic codes are a Pro feature (25 of them on Pro, unlimited on Business); a static PNG is free.

The rule of thumb: if the destination is decided and permanent, static is fine and costs nothing. If there is any chance you will want to change what it opens after the tickets are in envelopes, it has to be dynamic — that decision cannot be reversed later.

Printing it so it actually scans

Ticket stock is where QR codes fail most often, because tickets get folded, perforated and printed small on textured paper.

Keep the code at least 2cm across on a printed ticket. The working guideline is that a code scans from roughly ten times its own width, so a 2cm code wants the phone within about 20cm — fine for a ticket in someone's hand, not fine for a poster across a room.

Leave the quiet zone alone. The blank margin around the pattern is part of the code, not padding you can crop; scanners use it to find the edges. Never run the code over a fold or a perforation, and never place it in the tear-off stub if the stub is what gets kept.

Keep the contrast dark-on-light. An inverted code — light pattern on a dark ticket — is out of spec and a lot of phone cameras will simply not see it. The purple in this template is dark enough on white; if you recolour it, check the result against a real print, not the screen.

Codes generated here use error-correction level M, which tolerates roughly 15% of the pattern being damaged. That is the right level for a ticket: enough margin for a thumbprint or a slight fold, without inflating the pattern density the way level H does.

Test the printed ticket, not the preview

The preview on this page is a real, scannable code — scan it with your phone right now if you like. That still is not the test that matters.

Print one ticket on the actual stock, at the actual size, from the actual printer, then scan it: in the light you will have at the door, at arm's length, with the ticket slightly bent, and with a cheap phone rather than your own. Most QR failures at events are a print or lighting problem that was invisible on a monitor.

Questions people actually ask