QR Code Specifications

When someone reaches your check-in table — at a kirtan door, a retreat welcome desk, a festival gate — the QR code on their ticket is what turns a line of people into a fast, orderly flow. BrightStar builds that code with a specific format, a set of security checks, and a handful of ways to make it look like your event rather than a generic ticket. This article walks through what's actually in the code, why it can't be faked, how to size it for print, and how far you can push its look before it stops scanning.

Each code encodes a small payload rather than a picture of a barcode: a version number, the ticket's unique ID, the event ID, a checksum, and an expiry timestamp. That payload is also encoded as a plain URL — https://brightstarevents.com/t/TKT-ABC123-XYZ — so if a scanner can't read the code at all, whoever is on the door can type or tap that link in manually and still pull up the ticket. The version field exists because the amount of data in a QR code changes how dense the pattern is; BrightStar generates the version dynamically based on how much data a given ticket actually needs, rather than forcing every code into a fixed size. Encoding is UTF-8, so names and event details outside the basic Latin alphabet still fit into the payload correctly.

The checksum is the piece doing the security work. It's generated with HMAC-SHA256 using a secret key that's specific to the event, so even someone who understands the payload structure can't hand-craft a working ticket ID or edit an existing one — any change to the ticket ID, event ID, or expiry breaks the checksum and the code fails validation. Every code also expires, by default at the event's end plus a set window afterward, though that window is configurable per event, so a multi-day festival and a single evening kirtan can each expire on a schedule that actually matches how long check-in is expected to run. On top of that, each code is one-time use: the first scan checks someone in, and every scan after that returns "Already checked in" instead of letting the same code through twice. The one exception is re-entry mode, which an event can turn on when attendees are expected to leave and come back, such as a festival with an on-site camping area.

The code follows the standard QR format (ISO/IEC 18004) with error correction Level M, meaning it will still scan correctly even if about 15 percent of it is smudged, creased, or partly covered — a real concern for a paper ticket that's been folded in a pocket on the way to a retreat. For screens, BrightStar's minimum is 100 by 100 pixels, with 200 by 200 pixels recommended so a scanner has margin to work with in low light or from an awkward angle. For anything printed, use at least 300 DPI; below that, the fine modules of the code start to blur together and the error correction has to work harder to compensate. Color matters too — the default is black on white, and any custom color scheme still needs a dark foreground on a light background with a contrast ratio of at least 3 to 1, because a scanner is reading contrast, not aesthetics.

Within those limits, there's real room to make the code look like your event rather than a generic ticket. You can set custom colors as long as contrast holds, add a logo overlay in the center covering up to 30 percent of the code, apply a custom shape such as rounded corners, use a branded PDF ticket template, and issue Apple Wallet or Google Wallet passes. The 30 percent ceiling on a logo isn't arbitrary — QR error correction can only recover a limited share of missing or altered data, so a bigger overlay risks tipping a code from "still readable" to "unscannable" the moment it's also dealing with a fold or a scuff.