Does a screenshot contain personal information?

Screenshots usually carry little EXIF data, but photos from a phone camera often carry GPS coordinates, device model and a timestamp. If a tool uploads the whole file, it receives all of that too.

Can I verify what a website sends instead of trusting its claims?

Yes. Open your browser's developer tools, go to the Network tab, run the search, and inspect the outgoing request. The payload size and content tell you whether a full image or a small crop was transmitted.

Should I upload a photo of a real person I know?

No. Searching an adult-content index with an image of a private individual is a misuse of the tool, produces meaningless results, and raises obvious ethical and legal problems.

Is Uploading a Photo to a Search Tool Safe?

Safety depends on what actually leaves your device. Most image search tools upload the whole file to a server. A browser-side pipeline sends only a cropped face region and five landmark coordinates, so the original photo, its metadata and everything outside the face never leave your machine.

Safety is not a promise, it is an architecture. The only question that matters is what bytes actually leave your device, and any tool that uploads your whole file has already answered it — everything in that image is now on someone else's server, including whatever you did not think about.

The alternative is to do the sensitive part locally. When detection and alignment run in your browser, the server never sees the original image at all. It receives a small cropped face region and five landmark coordinates, which is the minimum needed to compute a vector.

What does a typical image search tool receive from you?

More than the picture. An upload is a file, and files carry context.

What gets transmitted	Whole-file upload	Browser-side detection
The full original image	Yes	No
Everything outside the face — room, other people, documents on screen	Yes	No
EXIF metadata (GPS, device, timestamp)	Yes, unless stripped	Not applicable — never sent
Cropped face region	Yes	Yes
Five landmark coordinates	Computed server-side	Yes
Your IP address and request headers	Yes	Yes

The last row is unavoidable for any network request, on any site. The rows above it are architectural choices, and they are where tools actually differ.

Note the second row in particular. Screenshots taken from a desktop often include far more than the video: a browser with logged-in tabs, a file manager, message notifications. A whole-file upload hands all of it over.

How does browser-side detection work in practice?

The detector runs as code loaded into your browser tab, operating on the image in local memory.

You select an image. It is read into the page — no network request happens.
YuNet runs locally and returns a bounding box plus five landmarks for each face found.
You choose which face to search, if several were found.
Only that cropped region and its landmark coordinates are sent to the server, which computes the 512-number ArcFace vector and searches the index.
Results come back. Nothing about the request is retained afterwards.

The practical consequence: an image that never contained a detectable face never generates any upload at all. The failure happens entirely on your side.

What questions should you ask any tool before uploading?

Five, and all of them have observable answers rather than marketing answers.

Question	How to check it yourself
Does the whole file leave my device?	Developer tools → Network tab → inspect the request payload size
Is the connection encrypted?	HTTPS, with a valid certificate — check the address bar
Is the image stored after the search?	Read the privacy policy; absence of a retention statement is itself an answer
Is the image used for training?	Look for an explicit statement. Silence usually means yes
Does it require an account?	An account links every search to a durable identity

The last one is underrated. A tool that works without registration cannot build a search history tied to you, regardless of what its policy says.

What are the real risks, ranked honestly?

Not all risks are equal, and the loudest fears are often not the largest ones.

Highest: uploading images of private individuals. This is the risk that is genuinely serious, and it is created by the user, not the tool. Searching an adult-content face index with a photo of a classmate, colleague or ex-partner is harassment infrastructure, not research. It also does not work — the index contains published promotional imagery, so a private person simply returns a list of strangers with low scores, which people then misread as a finding.
High: accidental context in the frame. A screenshot that includes your desktop, open tabs or an email client leaks more about you than the video does.
Moderate: retention and reuse. Images kept on a server can later be breached, subpoenaed or repurposed for training.
Low: the face crop itself. A 112-pixel aligned face crop of a published performer, sent over TLS and not retained, is close to the minimum viable disclosure for this task.

What does this tool do specifically?

Detection runs in your browser. Only a cropped face region and five landmark coordinates are sent to the server. The original image never leaves your device, and results are not stored.

That claim is deliberately falsifiable — open the Network tab and watch. We state it that way because "we respect your privacy" is not verifiable and a request payload is.

What we do hold is the index being searched: 241,792 faces across 106 sites, 2,333 of them linked to a named performer (our index, 2026-08 snapshot). That material is public promotional imagery for published adult releases. It is not a database of private people, and it will not behave like one.

Boundary worth stating: no architecture removes the fact that a request carries an IP address, or that your network operator sees a connection to a domain. If you need protection at that level, that is a network problem and it needs a network solution, not a better upload form.