How selfie search for event photos works, and what happens to the face data

After any big event (a wedding, a conference, a 10K race) someone ends up holding a folder of a few thousand photos. Everyone in those photos wants the handful they're in. The usual ways of handing them out are a shared Drive or Google Photos link, where everyone scrolls through everything and anyone with the link sees all of it, or a group-chat dump, where photos get buried and recompressed.

Selfie search is the pattern a lot of event-photo tools have settled on: a guest takes one selfie, and the system returns only the photos that guest appears in. We build one of these tools, FotoNest. This post walks through how the flow works and, because it's what people actually ask about, what happens to the face data at each step.

The guest flow

From the guest's side there are five steps:

1. Open the event. The host gets one QR code and one shareable link per event. A guest scans the code or taps the link, in the Android app or in any browser.
2. Sign in with Google. One tap: no password, no OTP, no phone number.
3. Tap "Find my photos" and take one selfie.
4. See the matches. Only the photos you appear in, ranked by how strongly they match.
5. Download. One at a time or in bulk, as the original full-resolution files.

The photos arrive from the other direction. The host, the photographers and, depending on the event's privacy mode, the guests add them from a phone camera, a phone gallery, a public Google Drive link or desktop drag-and-drop. Several photographers can upload to the same event at once, and uploads resume if the connection drops.

What happens between the selfie and the results

Face search systems generally work in two halves.

Cataloguing the gallery. When photos are added, each face in each photo is detected and turned into an embedding: a list of numbers that describes the face in a way that stays stable across lighting, angle and expression. Two photos of the same person produce embeddings that sit close together; photos of different people sit further apart. This happens once per photo, not once per search.

Searching. The guest's selfie goes through the same process. The system compares that one embedding against the event's catalogue and returns the photos whose faces are closest, best match first.

In FotoNest, the selfie becomes an encrypted face embedding, it's matched only against the photos of the event the guest joined, and the results come back ranked by match. A few behaviours follow from that:

• Group selfies work. If several faces are in one selfie, the search returns photos of any of them, combined. One selfie with your friends returns everyone's photos.
• Angles and small obstructions are fine. Side and profile shots match, and so do faces behind small sunglasses, a hat or light makeup. A face that's mostly covered won't.
• Low light, children and twins were all tested, and all work.
• No tagging, ever. Nobody labels faces by hand.
• Late photos aren't pushed. If more photos are added after you've searched, you re-run your selfie to pick them up. It's a retrieval flow for after the event, not a live feed during it.
• No match is an answer too. You get a "photos not found" state and can search again later.

Matching quality is the number everyone asks for first. FotoNest's figure, from internal testing, is 99.8% match accuracy.

Why sign-in is required

Plenty of photo-sharing tools let anyone with the link browse. FotoNest requires Google sign-in for every guest on every event, with no exceptions. The reasoning: a gallery of people's faces shouldn't have anonymous visitors, so everyone inside one is a verified identity. Keeping it to one tap is what makes the requirement bearable at a wedding.

Two other controls do similar work:

• Searching is selfie-only. You search with your own live selfie. You can't upload someone else's photo to find them.
• Event URLs are auto-generated, with no custom slugs, so nobody can guess a URL from an event's name.

The three privacy modes

The host picks a mode when creating the event, and it locks once the event starts, so guests know exactly what they joined.

The PIN gates contributing, not viewing. In every mode, a guest's face-matched results are shown only to that guest.

What's stored, and for how long

This is the part worth being precise about, because one selfie turns into several pieces of data, and each has its own lifetime:

• A thumbnail of the selfie, so you can reopen your own recent searches. Only you can see it. It's never shown to the host or to other guests.
• The face embedding, for the life of the event. That's what makes a repeat search fast once the gallery has been catalogued.
• Your results, for about 72 hours, as server-side "recents".

Embeddings are encrypted at rest and stored separately from contact details, and they're used only to find a guest's photos within events that guest has joined. The selfie is never sold, never used for advertising and never used to train third-party generative-AI models.

How deletion works

Retention is tied to the event, not to a vague policy window.

• At event expiry, the event and all of its face data are permanently deleted, usually within about a minute. There's no grace period, no archive and no recovery. A paid event lasts as long as the host paid for, up to three years; a demo event lasts seven days.
• Guests can delete their face data, or their whole account, at any time. Deleting an account removes the account, its uploaded photos and its face embeddings. It's handled within 30 days and can't be undone.

Limits that keep it fair

• Up to 5 selfie searches per guest per day, and 2,000 per event per day. At the ceiling, search pauses for the rest of the day, but past results can still be reopened.
• No cap on guests or devices. The only limit is the plan's photo count, so a 1,000-guest wedding all scanning at once is within design.

If you're building something similar

What we'd tell anyone adding face search to a product:

1. Write down exactly what's kept. "The selfie" can mean the image, a thumbnail, an embedding and cached results. Each needs its own answer to "for how long?"
2. Tie deletion to an event you can point to. "Deleted when the event expires" is easier to trust, and to test, than "deleted after a reasonable period".
3. Keep embeddings away from identity data. Separate storage and encryption at rest limit what a single leak exposes.
4. Don't let people search for others. Live-selfie-only search closes the most obvious abuse path.
5. Require sign-in, but make it one tap. Friction is the usual reason tools skip it.

To see the whole flow, there's a free demo event (200 photos, live for 7 days, no card) at fotoneststudio.com.