Turn bib numbers into runner names with a roster CSV

A bib number is what the camera sees. A name is what a runner's family types into the search box. A roster is the thing that connects them, and in Bibbit it is a plain CSV with two columns.

The format

A header row, then one row per runner:

bib,name
101,Alice Okafor
102,Ben Carvalho
0103,Chen Wei

A bib column and a name column; column names are matched case-insensitively, so Bib,Name is fine. If the export you were given has first and last columns (or first name and last name) instead of a single name, Bibbit joins them, so you don't have to rebuild the file.

Upload it when you create the event. The same roster applies to every gallery in the event, so one file covers the start, the course and the finish.

The rules Bibbit applies

A few rules explain what you will see in review.

A bib is text, not a number. Bibbit never converts the bib column to a numeric value. 0103 stays 0103. Spreadsheet software is the usual culprit here: open the CSV in a spreadsheet and the leading zero vanishes on save. If the race uses padded bibs, check the file in a text editor before uploading.

Whitespace is trimmed, and nothing else is changed. 101 becomes 101. The canonical bib, exactly as it appears in your file after trimming, is what gets written to the photo.

Duplicate bib rows merge their names. Two rows with bib 205 and different names become one entry with both names. That is how relay teams and shared bibs are handled without special syntax.

Several names on one row are separated by a semicolon. 205,Dana Ruiz; Eli Ruiz is the same as two rows. Commas are column separators, so a semicolon is the one character that works here.

A bib with no name is rejected; a blank row is skipped. The upload fails with the bib number named, so you can fix the file rather than hunt for the gap.

How matching uses the roster

When Bibbit reads a bib in a photo, it compares the detected digits with the roster using a normalised key: non-digits stripped, leading zeros stripped. So a detection of 103 matches the roster entry 0103, and the keyword written is 0103, the canonical form from your file, not the raw detection.

If two roster entries normalise to the same key (0103 and 103, say), a detection matching both is flagged for review rather than tagged automatically. The same goes for any ambiguous read.

The roster also reaches photos where no bib was readable. When a face group is resolved to a bib number, every photo in the group gets that bib's name as well.

Where to get a roster

Unless you are the organiser, the roster is someone else's data, and the two places it lives are:

The timing company. Chip timing companies hold the definitive bib-to-name list, including race-day registrations and bib reassignments. Ask for an export with bib and name columns. Ask early; the post-race results export is the same data plus times.

The registration platform. The organiser can export entrants from whatever platform handled sign-ups. The columns will have other names and plenty of extra fields; delete everything except bib and name, and rename the headers.

Either way, ask for the export after bib numbers are final. Race-week transfers and on-the-day entries are the usual source of a roster that is a few names out, and a roster that is out means a name on the wrong runner's photos. If you receive an updated file later, re-upload it; the next review and sync use the new names.

What gets written to the photos

With a roster, each approved photo receives:

• the bib number, as a keyword, exactly as the roster spells it
• the runner's name, as a keyword, exactly as the roster spells it (one keyword per name if a bib has several)
• the marker keyword bibtool:bibbit, which lets a later sync recognise its own work

Names ride in the same keyword field as bibs, so the host's search box finds a runner by either. On SmugMug a comma searches several keywords at once, so Alice, Okafor works. On Zenfolio, Exact Match (the setting that stops 100 matching 1001) also means a name has to be spelled the way the roster spells it; the gallery search guide covers the trade-off per host.

Nothing you already had on the photo is touched. Sync merges keywords, never replaces them, and running it again never duplicates a tag. Without a roster, bib numbers alone are still written and search still works; the roster only adds names.

Only publish names people expect to be published

A bib number on a public photo is already public: it is printed on the runner's chest. A name attached to a face in a public gallery is a different thing, and whether it is appropriate depends on the race.

The practical test is whether the race's entrant list or results are already public with names on them. Most road races publish full results by name, and participants entered expecting that; a name keyword on a photo is the same information. Youth races, school events, charity events with anonymous entry options, or any race where the organiser's privacy terms say entrant data stays with the organiser, are a different case: use the bib number only.

The roster is optional, and bib-only tagging still gives every runner a working search. And because of the marker, Bibbit's own keywords can be removed cleanly later, so taking names down is a sync, not an afternoon.

If you aren't sure, ask the organiser; they know what entrants agreed to.

Try it on your next event

Create an event, upload the roster, scan a gallery and watch numbers turn into names in review. Get started free.