There are two halves to any registration workflow: collecting who is coming, and recording who actually turned up. Most tools do one or the other well. A form collects names into a spreadsheet; a ticketing platform issues passes but wants to own the whole event and take a cut. The gap in the middle is where most small events sit.
This guide covers the free route honestly before the paid one, and is written by people who sell one of the options. The bias is disclosed.
Why a Google Form cannot do this alone
A Google Form writes each response as a spreadsheet row, which is genuinely most of the job. What it cannot do is produce something unique for that person to present later. There is no per-response image, no confirmation email with an attachment, and no concept of a code that can be checked off.
The free workaround is an Apps Script bound to the response sheet. On each submission it builds a URL containing the row's unique id, points a QR image service at that URL, and emails the result with MailApp. This works and costs nothing, and for a one-off event with a technical organiser it is a reasonable choice.
Three things tend to bite. MailApp has a daily quota that is lower on a consumer Gmail account than on Workspace, so a form that performs well stops emailing partway through. The script runs on Google's trigger schedule, so a failure is silent and the registrant simply never receives anything. And critically, generating the code is only half the problem: you still have nothing to scan it with, so the check-in half needs a second build.
If you build the Apps Script route, log the outcome of every send into a column on the same row. A registrant who never received their code is invisible otherwise, and you find out at the door.
What a per-submission code actually needs to be
- Unique to one submission, so two people cannot present the same pass.
- Meaningless on its own, so a photographed code reveals nothing about the person.
- Reachable without an app, because a stranger will not install one to attend your event.
- Idempotent on scan, so scanning twice does not double-count or read as a second arrival.
- Recorded somewhere you own, not inside a vendor dashboard you have to export from.
That last point is the one people regret skipping. If arrivals are recorded inside a platform, reconciling who registered against who came means exporting two files and matching them by hand. If both land in the same spreadsheet, it is one column.
How this works in QR to Sheets
Each submission generates its own token and a QR code encoding a check-in URL for that token. The code appears on the confirmation screen immediately and, when the confirmation email is switched on, in the email as well. Nothing is installed by the registrant, and nothing is installed by the person scanning.
The check-in code deliberately points at a separate check-in route, not at a scanner link. That means checking in a registrant never consumes a device licence and never touches the per-device paywall, so the number of people you check in has no effect on what you pay.
Scanning is idempotent. If a code is scanned twice, the second scan reports that the person is already checked in and returns the original arrival time rather than overwriting it. On a busy door where two volunteers both scan the same guest, that is the difference between an accurate head count and a wrong one.
| Capability | Google Forms + Apps Script (DIY) | QR to Sheets |
|---|---|---|
| Cost | Free, within Apps Script and Gmail quotas | Free for 10 trial submissions, then 7 USD per registered device per month |
| Unique code per registrant | Possible, but you write and maintain the script | Generated automatically for every submission |
| Delivery to the registrant | MailApp, subject to a daily quota that differs by account type | Shown on the confirmation screen and emailed |
| Scanning at the door | Not included — needs a second build | Any phone opens a link; no app, no account for the person scanning |
| Scanning the same code twice | Whatever you build it to do | Reports already checked in and keeps the original time |
| Where arrivals land | Wherever your script writes them | The same Google Sheet as the sign-ups |
| Does check-in cost a device licence | Not applicable | No — check-in uses a separate route that consumes no device slot |
Printing and screen: what actually fails on the day
A QR code only scans reliably as dark modules on a light background. If you place the code into a branded email or a printed pass, keep the code itself dark on near-white and leave the blank margin around it intact. Cropping that quiet zone to make a design fit is the single most common reason a code stops reading.
Phone screens are usually fine, with two exceptions worth telling registrants about: auto-brightness turned right down, and a cracked screen across the code. Both are solved by having the email as a fallback, which is why delivering the code twice matters.
When this is the wrong tool
If you are selling tickets, use a ticketing platform. This is not one: there is no payment collection, no seat allocation, no ticket transfer and no refunds. Trying to bolt payment onto a form is how people end up reconciling a spreadsheet against a payment processor by hand.
If your event is small enough that a printed list and a pen works, that also genuinely works, and it does not fail when the venue wifi does. The case for codes starts when the queue matters, when you need arrival times, or when the person on the door does not know the guests by sight.
Step by step
- 1
Decide what the code has to prove
Usually it proves that this specific person registered. That means the code must be unique per submission, not one shared code printed on a poster, which proves only that somebody found the poster.
- 2
Turn the QR code on when you build the form
The per-submission QR code is a switch on the form, and it is off by default. A form built without it collects responses perfectly well but issues nobody a pass, which is only discovered on the day.
- 3
Deliver the code twice
Show it on the confirmation screen for people who register on their phone, and email it for everyone else. Someone who registers on a laptop at work needs it on the phone they will actually bring.
- 4
Decide who scans, and on what
The person on the door opens a scanner link on their own phone. They need no account and install nothing, so a volunteer or venue staff member can be handed the job an hour beforehand.
- 5
Test the whole loop before you publish the form
Submit the form yourself, open the email, and scan your own code at the door setup. This takes two minutes and is the only test that proves registration, delivery and check-in all connect.
- 6
Watch the sheet on the day
Arrivals land as rows in the same spreadsheet as the sign-ups. Anyone you have shared that sheet with can watch the count from anywhere, without being at the door.
Frequently asked questions
Can Google Forms send a QR code to each person who submits?+
Not by itself. Google Forms has no per-response image generation and no confirmation email with content you control, so it requires an Apps Script that builds a QR URL and sends it with MailApp, subject to that account's daily sending quota.
Does the registrant need an app to use their QR code?+
No. The code is delivered as an image on the confirmation screen and in the confirmation email. They show it on their phone screen or on paper, and the person scanning uses a browser link with no app either.
What happens if the same code is scanned twice?+
The second scan reports that the person is already checked in and returns the original check-in time rather than overwriting it, so a double scan on a busy door cannot corrupt the head count.
Does checking people in use up my device licences?+
No. Form check-in uses a separate route from scanner links, so it never registers a device or consumes a device slot. Device licences are for scanner links, at 7 USD per registered device per month.
Is the QR code turned on by default?+
No. The per-submission QR code is a switch on the form and it is off when you create one, along with the Google Sheet, webhook and confirmation email deliveries. Turn on the ones you need before publishing the form.
Can I use this for paid tickets?+
No. There is no payment collection, seat allocation or ticket transfer. For paid tickets a ticketing platform is the right tool; this is for free registration and check-in where the data should land in your own spreadsheet.