Race Photography Photo Delivery: Free Photos for Every Runner

Be clear with the organiser about this before race day.

The client page on clientgallery.io has one search: face search. There is no bib number search and no text search on the gallery page. A runner either searches by face, or scrolls.

That shapes everything else in this guide. The structure of the galleries has to make scrolling tolerable for the runners who will not or cannot use face search, and face search has to be set up so it works for the ones who will.

If the organiser has promised runners a bib lookup, this is not the right platform for that race.

Face search lets a runner give a selfie and see only the photos that match it. These are the facts that matter when you explain it to an organiser:

• It is off by default and switched on for one gallery at a time.
• Matching runs entirely in the runner's own browser.
• The selfie is never uploaded.
• The gallery's face index sits behind the gallery password.
• It works on the main gallery link, not on a section's own link.

Two things the product does not give you, so do not promise them. There is no consent step: the runner sees a short explanation and a file picker. And switching face search off, or deleting a gallery, is not something to describe to runners as erasing face data.

So the decision to switch it on belongs to the organiser. Ask in writing. If registration terms or the race-day announcements do not tell participants it will be available, leave it off.

The privacy detail is set out in face recognition and gallery privacy, and how matching works in face recognition in a guest gallery.

Face matching is a similarity search, not identification. Race conditions are harder than a conference lobby, and runners should hear that from you rather than discover it.

After a search, one tap on the results button brings the whole gallery back. That is the fallback for every runner the search misses.

A gallery holds up to 1,000 photos under fair use. A race with several photographers will pass that, so you will deliver more than one gallery. Galleries are unlimited under fair use, so the only question is where to cut.

Cut where a runner knows where they were. A runner remembers the start, the halfway bridge and the finish arch. They do not remember a time of day or a photo count.

Sections are one level deep and arranged studio-side. The runner sees one scrolling page with a jump bar at the top showing how many photos each section holds. Naming sections by passing time, such as “Finish, 9:30 to 10:00”, lets a runner who knows their finish time skip straight to the right stretch.

Face search runs per gallery. A runner who wants every photo of themselves searches each gallery they passed through. Say so on the organiser's results page, next to the list of links.

1. Switch picks off. Everyone on a gallery link shares one pick set, and sending picks locks picking for all of them. Picks are for one client choosing, not a field of runners.
2. Leave downloads on. Each photo gets its own download button, and the page offers a “Download all photos” button for the whole gallery. A runner will use the single-photo button.
3. Set a password if the organiser wants one. It covers the gallery, every section, the downloads and the face index. For a public race, a password circulated to every participant is a speed bump against the open web, not a guest list.
4. Switch face search on only with written agreement, per the section above.
5. Write a welcome note. It appears under the gallery title. Use it to say which course point this gallery covers, how to search, and what credit the organiser wants when runners post.
6. Publish a first batch the same day. The finish line is what runners look for first. Adding photos later does not change the link.

The client pages carry your studio name and logo with no platform branding, on your own subdomain. For a sponsored race, that page is the sponsor's and your advertisement, not ours.

The organiser needs two things runners do not: a full set for their own communications, and a way to know the galleries are being used.

For the full set, a paid account can attach a full-resolution ZIP to any gallery. It stays live for 3 days per upload and can be uploaded again at any time. Send the organiser the gallery link and tell them when the ZIP is up.

For usage, the studio analytics are account-wide, not per gallery: gallery visits, unique visitors, photo views, ZIP downloads, shares, time spent, a device split and the five most-viewed photos. Visitors are counted without being identified. If this race is the only job running that week, those account totals are a fair picture of the race. There is no per-runner report.

If runners pay for their photos, use a platform built for that. clientgallery.io has no per-photo checkout, no print store and no commissions. You can paste a payment link on a gallery, but downloads do not unlock when someone pays; switching them on is manual, per gallery, which cannot work for thousands of individual buyers.

If the race needs bib number lookup, choose a platform that documents it.

clientgallery.io fits the photographer paid by the organiser or a sponsor, handing free photos to every participant, who wants flat pricing and no per-gallery fee however many galleries a race weekend produces.

The service hosts JPEGs sized for viewing. It does not keep your RAW files, so a race archive still lives on your own drives.

This page states no external figure. Every number on it is a clientgallery.io product fact, checked against the product code on 24 September 2026: the plan prices, unlimited galleries under fair use, the fair-use ceilings of 1,000 photos per gallery and 250 GB per paid account, and the 3-day full-resolution ZIP with 100 GB of standing ZIPs. The client page behaviour (face search as the only search, no bib or text search, one shared pick set that locks when sent, per-photo and whole-gallery downloads, the show-all control after a face search) and the account-wide analytics were checked in the same code on the same day.