A 5K registration form looks like a short form until you write down everything it has to carry. There is the runner, the emergency contact, the age group, the shirt, the waiver, the entry fee, and the question of whether a parent has to sign for anyone under eighteen. Then race week arrives and the same list has to produce bib assignments, a packet pickup sheet, a shirt order, and a file the timing company can read.
Most of the pain in running a small race is not the form. It is the three weeks after the form, when the registration list has been copied into four other places and none of them agree. This is a guide to building the form so that the list it produces is the only list you need.
What a 5K registration form has to capture
Split the fields into three groups, because they are wanted by three different people at three different times.
What the runner needs to give you to enter. Name, email, date of birth, gender if the results are scored by category, and the waiver. This is the minimum set and it should be the only thing standing between a visitor and a completed entry.
What the race needs to run the event. Emergency contact name and phone, shirt size, whether they want the shirt at all, and any accessibility or medical note they choose to volunteer. A stroller or wheelchair division question belongs here too if you offer one.
What you want for next year. Where they heard about the race, whether this is their first 5K, whether they would like to hear about the next one. Ask these last, mark them optional, and accept that a share of people will skip them.
The order matters more than most organisers expect. Anything that feels like a hurdle near the top of the form costs entries. The waiver is the obvious example. Put it near the end, after the runner has already invested a minute in filling things in, rather than as the first thing they see.
Date of birth, not age
Ask for date of birth rather than age, and derive the age group from it. Races are almost always scored by age on race day, not age on registration day, and a 5K that opens in January for a June event will have runners who change category in between. Storing the date means the category can be recalculated. Storing "34" means it cannot.
The waiver, and what you actually need to keep
The waiver is the field that turns a registration form into a legal record, and it is the one most likely to be set up carelessly.
The mechanics are simple. Put the full waiver text on the form, not behind a link, so the person has seen it. Follow it with a required checkbox and a required text field where they type their full name. The combination of the text shown, an affirmative action, and a typed name is the standard shape for an online waiver, and it gives you something to point at later.
What you keep matters as much as what you collect. For each entry you want the waiver text as it stood on the day they agreed, the timestamp, and the name they typed. If the waiver wording is edited mid season, entries made before the edit agreed to the old text, and an export that only stores "waiver: yes" cannot tell you which version anyone saw.
Whether an electronic waiver holds up is a question for the race's insurer and for local law, not for a form builder. Practice varies by jurisdiction, and the safe move is to send the exact wording and the exact mechanism to whoever writes the policy and get it in writing before registration opens.
Minors
If the race admits under eighteens, the form needs a branch. When the date of birth puts the runner below the age of majority, show the parental consent section: guardian name, relationship, guardian email, and a second agreement. Conditional logic that hides this section from adult entrants keeps the form short for the majority while still catching the minority who need it. Handling this as a branch inside one form is simpler than running a separate junior entry form that somebody has to remember to link.
Shirt sizes, and why the cutoff matters more than the sizes
The shirt is the part of a 5K registration that most often goes wrong, and it goes wrong for a scheduling reason rather than a data one.
Shirt orders have a lead time. The printer needs numbers by a date, and registrations keep arriving after that date. If the form offers a shirt to everyone who registers, you have promised something to people whose sizes were never in the order.
The fix is to state the cutoff on the form itself, next to the size field. Something plain: shirts are guaranteed for entries received by a stated date, and entries after that get a shirt if any are left. Then, on that date, close the size question or switch it to a note. A form tool that lets you change a live form without breaking the link makes this a two minute job on the day.
Sizing questions worth asking
Offer unisex and fitted cuts as separate options if you order both, because "medium" means different things across the two and a single size list will produce complaints at packet pickup. Include a youth range if children run. Add an explicit "no shirt" option, which costs nothing and saves shirts.
The size distribution from last year's race is the best predictor you have for this year's order. That is only true if last year's registration data still exists in a form you can count, which is an argument for keeping the list somewhere more durable than a spreadsheet on somebody's laptop.
Fees, refunds and the questions people will email about
If the race charges, the form and the payment should be the same step. Registration that ends with "now send us the fee separately" produces a reconciliation job: a list of entrants, a list of payments, and a manual match between them with a handful that never line up.
Whatever the payment method, write the refund policy on the form above the pay button. Small races get the same three questions by email over and over: whether refunds are possible, whether an entry can be deferred to next year, and whether it can be handed to a friend. Answering all three in two lines on the form removes most of that traffic before it starts. A common shape is no refunds, deferral allowed up to a stated date, and transfers handled by the organiser rather than privately, so that the waiver and the emergency contact match the person on the course.
An automatic reply sent on submission should repeat the fee paid, the refund policy, and the date, time and start location. That email becomes the entrant's record, and it is what they will search for the night before the race.
Capacity
If the course, the permit or the parking caps the field, decide in advance what happens when the cap is reached. The two workable answers are closing the form with a message that says the race is full and pointing at a waiting list, or leaving it open and switching to a waiting list question. Both are better than the third option, which is discovering the overshoot in the week before the race and telling forty people they cannot run. A form that can be closed on a date or on a count, with wording you choose, turns that into a setting rather than a decision somebody has to remember to make on a Sunday night.
Where the registration list should live
Between registration opening and race day, the same list gets used by the shirt printer, the timing company, the packet pickup volunteers and whoever answers the email. How it is stored decides how many copies of it exist.
| Approach | Good at | Where it costs you |
|---|---|---|
| A free form plus a spreadsheet | Costs nothing, set up in an afternoon | Waiver versions are not kept, no status per entrant, replies happen in a separate inbox |
| A race registration platform | Built for racing: age groups, bibs, timing exports, payment | A per entrant fee, and the data sits inside that platform |
| A form tool with response management | One list from entry through race week, each entrant carries an owner and a status, replies sent from the same screen | Race specific features such as bib assignment have to be set up as fields |
For a first year community 5K with a few hundred entries, a general form tool with a proper response list is usually enough, and the cost difference against a per entrant platform is large. For a race with chip timing, wave starts and a prize structure, a racing platform earns its fee. The question to ask is how much of what the platform does you would otherwise build by hand.
If the choice comes down to cost, look closely at how each option is priced. Pricing that counts responses behaves very differently from pricing that counts the people on your team when a single registration window brings in a thousand entries in a week.
Race week, and what the list has to produce
Registration closes and the list turns into paperwork. Four things come out of it.
The bib list. Numbers assigned to entrants, usually alphabetical or by category. This is a column added to the list, not a separate document, so that the bib number is visible next to the entrant everywhere else.
The timing file. Whatever columns the timing company asks for, in their order. Ask for the template early. It is much easier to name your form fields to match their template than to reshape a CSV the night before.
The packet pickup sheet. Name, bib, shirt size, and a box to tick. Whoever is behind the table needs to find a runner by surname in a second, and needs to mark that the packet was collected.
The follow up list. After the race: results, photos, thanks, and the date of the next one. That email performs better than anything else you will send all year, and it works only if the entrant list is still intact and still has valid email addresses attached.
All four come from the same rows. The reason to keep entrants as records with their own fields and status, rather than as lines in a sheet, is that marking "packet collected" or "deferred to next year" against a person is then visible to everyone rather than living in one volunteer's copy. Registration and the follow up that comes after it work better when they are the same list.
What to change first
Get the waiver right before anything else, because it is the field that cannot be fixed retroactively: full text on the form, a required checkbox, a typed name, and the version stored with each entry. Then put the shirt cutoff date next to the size question, which removes the single most common race week complaint. If entrants are currently scattered across a form, a spreadsheet and an inbox, see what one list from entry to race day looks like in Halict before next year's registration opens.
Q1. Does an electronic waiver count as a signature for a 5K?
Practice varies by jurisdiction and by insurer, so the answer has to come from whoever writes the race's policy. What is within your control is the record: show the full text on the form, require an affirmative action, require the runner to type their full name, and store the wording and timestamp with each entry. Send that exact setup to the insurer before registration opens.
Q2. Should the shirt size be required?
Make it required but include a "no shirt" option. A required field with an opt out gives you a complete count for the printer, while an optional field leaves blanks that somebody has to chase. State the guaranteed shirt cutoff date next to the field so late entrants know what they are getting.
Q3. How do you handle runners under eighteen?
Use the date of birth to trigger a conditional section asking for a parent or guardian name, relationship, contact details and a separate agreement. Keeping it as a branch inside the main form is easier to manage than a separate junior form, because there is one list at the end rather than two that have to be merged.
Q4. What is the minimum set of fields for a small charity 5K?
Name, email, date of birth, gender if results are scored by category, emergency contact name and phone, shirt size, and the waiver. Everything beyond that is optional and should be marked as such. Marketing questions belong at the bottom, after the entry is effectively complete.
Q5. Can one form handle several distances on the same day?
Yes. Add a distance field at the top and use it to show only the relevant questions, since a 5K and a half marathon usually need different cutoffs, fees and waiver wording. Storing everyone in one list keeps packet pickup and the timing export simple, because both of those want a single file.