Image search tools are not competing implementations of one idea. They belong to two families that answer different questions, and choosing the wrong family guarantees failure no matter which product inside it you pick.
Family one asks "where else does this picture appear?" Family two asks "whose face is this?" If you are holding a screenshot from a video player, only the second question has an answer.
What is the actual difference between the two families?
Near-duplicate matchers build a fingerprint of the whole image and look for matching fingerprints in a crawl of the web. Face-vector engines locate a face, normalise it, encode it into numbers, and compare those numbers against an index of faces.
| Near-duplicate matching | Face-vector matching | |
|---|---|---|
| Core question | Where does this image appear? | Whose face is this? |
| Unit compared | Whole-image fingerprint | Aligned face → numeric vector |
| Requires the exact image to exist online | Yes | No |
| Cropping to the face | Hurts — removes the signal | Helps — that is the input |
| Different pose, lighting, year | Usually fails | Designed to survive it |
| Works on a frame you captured | No | Yes |
| Typical failure mode | Returns unrelated stock imagery | Returns real people with low scores |
The row that decides everything for video frames is the third. Pause a player and screenshot it and you have created an image that has never existed on the web as a file. There is no copy to find, so near-duplicate matching has nothing to work with — this is a structural limit, not a quality gap.
What does each major tool actually do?
Grouping by behaviour rather than brand makes the choice obvious.
| Tool | Family | What it matches | Where it breaks on video frames |
|---|---|---|---|
| Google Images / Lens | Near-duplicate + visual similarity | Whole image against Google's crawl | Adult sites are largely absent from the crawl and suppressed by SafeSearch |
| Bing Visual Search | Near-duplicate + region search | Whole image or a selected region | Same crawl-coverage problem for adult catalogues |
| TinEye | Strict near-duplicate | Exact and edited copies of the same file | Explicitly a copy-finder; a novel frame has no copies |
| Yandex Images | Near-duplicate + strong visual similarity | Whole image, with looser similarity ranking | Often returns visually similar strangers, which reads as a match but is not |
| General "face search" web tools | Face-vector | Faces indexed from the open web | Index is built from open-web and social imagery, not adult catalogues |
| Adult-indexed face search | Face-vector | Faces indexed from adult covers and stills | Limited to what those sources published |
Yandex deserves a specific warning. Its visual-similarity ranking is loose enough to return people who merely look alike — same hair, same pose, same colour palette. Users read that as identification. It is not; nothing in that pipeline is measuring identity.
Why does the index matter more than the engine?
Because retrieval can only return what was indexed, and no algorithm compensates for absent material.
A face-vector engine trained to state-of-the-art quality, pointed at an index of open-web photographs, will not find an adult performer whose images live only in catalogues that index never crawled. The engineering is irrelevant to the outcome.
Ours is built specifically on this material: 241,792 faces from adult covers and stills across 106 sites, with 2,333 linked to a named performer (our index, 2026-08 snapshot). That is the entire reason it can answer a question Google cannot.
Boundary worth stating: our coverage is skewed. 2,246 of those 2,333 named performers have their representative image from a single source. Anything outside the catalogues we cover is invisible to us, and we will still show you a ranked list of near-misses — which is why every result carries a score, with 0.40 as the calibrated threshold for video stills.
How do the tools differ on what you hand over?
Comparison usually stops at result quality, but the privacy architectures differ more than the algorithms do.
| Behaviour | Typical whole-file upload tool | Browser-side detection |
|---|---|---|
| Original image transmitted | Yes | No |
| Metadata (GPS, device, timestamp) transmitted | Yes, unless stripped | Never sent |
| Content outside the face transmitted | Yes | No |
| Sent to the server | Full file | Face crop + 5 landmark coordinates |
| Verifiable by the user | Only by policy claim | Yes — inspect the network request |
Most tools in both families upload the whole file, because it is simpler to build. Running detection client-side means the server never receives the original at all.
What the major services say about the uploads they receive varies more than you might expect, and the useful distinction is between a stated policy and silence.
| Service | On keeping uploads | On training use |
|---|---|---|
| Saved only if visual search history is on, which is off by default | If it is on, images may be used to train its visual search models; training copies are kept up to four years, detached from the account | |
| Bing Visual Search | No retention period published | Says photos may be used to improve its image processing; does not use the word "train" |
| Yandex Images | No image-specific statement | No image-specific statement |
| TinEye | States uploads are deleted after results are shown and never added to its index | No statement either way |
Read the empty cells as unknowns, not as reassurances. Two further traps: the generous "we don't train on your images" language people quote at Microsoft belongs to its image generation product, not to visual search; and the Google default above is documented for its app and Lens surfaces, with no equivalent statement covering a signed-out desktop upload.
Sources: each service's own published help or policy pages; checked 2026-08-03.
Which one should you actually use, and when?
- You have a published image — a cover, a promotional still, something that exists as a file on the web: a near-duplicate matcher is the right first move. It can find the exact page it came from.
- You have a frame you captured yourself: go straight to face-vector search. Near-duplicate matching will not work and retrying it will not change that.
- You have a face but suspect the person is not an adult performer: no adult-indexed engine will help, and using one on a private individual is a misuse of the tool, not a clever workaround.
- You have a code or title text: skip image search entirely. Text lookup is faster and more reliable than any visual method.
A useful one-test diagnostic before you invest time in any tool: crop your image to just the face and run it again. If results get worse, that tool is doing near-duplicate matching and cannot identify anyone.
Related questions
- Why Google reverse image search doesn't work for adult videos
- How face search works, step by step
- Is uploading a photo to a search tool safe?
- How to find a video from a single screenshot
- Common mistakes people make when searching for a source
The comparison is easiest to settle empirically: run the same frame through a near-duplicate tool and through face search here. Detection runs in your browser — the original never leaves your device, and every result shows its score.