How is this different from the visual product search use case?

Visual product search is catalogue browsing — a shopper's photo returns a ranked list of similar products to buy, and a mediocre match is still a useful suggestion. Reverse image search is a verification check on a single incoming photo — the question is whether a specific match exists in your library at all, so a mediocre match should be rejected rather than shown, which is why the confidence threshold matters much more here.

What confidence threshold should I set for a valid match?

There's no fixed number that works everywhere — it depends on how similar your library images are to each other and how costly a false positive is for your workflow. Start conservative, review a sample of borderline results, and adjust the threshold based on where you actually see incorrect matches slipping through or good matches getting rejected.

Does the user's photo need to be hosted online first?

No. You can send it directly as base64-encoded bytes through the 'images' field, which is the usual path for a photo a user just uploaded from their device. If the photo already lives at a public https URL, you can pass that URL instead — either works, but not both in the same request.

What happens if there's genuinely no match in my library?

The nearest-neighbour lookup will still return the closest vector it can find, because similarity search always returns something. That's exactly why the confidence threshold exists on your side — below your chosen threshold, treat the result as no match, since a low similarity score for the 'best available' candidate is not the same thing as a real match.

When is reverse image search the wrong tool?

It won't tell you if two images are pixel-for-pixel identical — that's a job for file hashing, not embeddings. It also doesn't read text baked into an image, count or localise multiple objects within a frame, or verify authenticity or ownership; it only reports visual similarity to what's already in your indexed library, so it's not a substitute for a proper rights-management or OCR system.

USE CASE

Reverse image search against your own image library

Use case: Reverse image search with a single uploaded photo

Reverse image search answers a narrower question than catalogue browsing: given one photo someone just handed you — a screenshot, a competitor's product shot, a customer's snapshot of a damaged item — does anything in your own image library match it, and how confident should you be in that match? Webanto embeds the uploaded photo with DINOv3 into a 1280-dimensional vector and compares it against your pre-indexed library, returning the closest candidates ranked by similarity. Unlike a bulk indexing job, this is a one-off, ad-hoc lookup: a single query image comes in, gets embedded, gets compared, and the result either clears a confidence bar or it doesn't. Below that bar, the correct answer is no match at all, not a forced best guess dressed up as a real result.

What to expect

Support and operations teams can check an incoming photo against known reference images without a human manually scrolling a library.
A confidence threshold on the similarity score means low-quality or unrelated queries return nothing rather than a misleading closest-available result.
Query cost is tiny and predictable per lookup — a single-image embedding call, not a batch job — so ad-hoc verification workflows stay cheap even at moderate volume.
The same indexed library can answer many different one-off queries over time without re-indexing, as long as the library itself hasn't changed.

How to set this up

1
Pick the reference library this feature checks against — a design-asset archive, past product photography, or a set of previously verified images — and give every entry a stable id.
2
Index that library once via POST /api/v1/image-embeddings using 'urls' (https only) or 'images' (base64), up to 60 per batch, storing each 1280-dimensional vector against its id in your own vector store.
3
For a 15,000-image internal library that's 15,000 divided by 20 per credit = 750 credits for the one-time index — a small fraction of even the Starter plan's 10,000 monthly credits.
4
At query time, accept the uploaded photo from a user or system. If it's a raw upload, base64-encode it into the 'images' field for a single-image request; if it's already hosted at an https URL, pass 'urls' instead — and keep in mind the endpoint's roughly 4.5MB request body limit, so downsize large phone-camera photos before sending.
5
Embed the query photo and run a cosine-similarity nearest-neighbour lookup against the indexed library vectors.
6
Apply a confidence threshold to the top result. Only surface candidates above that threshold as a match; treat anything below it as 'no match found' rather than returning the closest vector as if it were reliable.
7
Log every query — the top candidate's id, its similarity score, and whether it cleared the threshold — so you can retune the threshold as real false positives and false negatives show up in production.

Products that power this use case

Webanto AI API

Frequently asked questions

How is this different from the visual product search use case?
Visual product search is catalogue browsing — a shopper's photo returns a ranked list of similar products to buy, and a mediocre match is still a useful suggestion. Reverse image search is a verification check on a single incoming photo — the question is whether a specific match exists in your library at all, so a mediocre match should be rejected rather than shown, which is why the confidence threshold matters much more here.
What confidence threshold should I set for a valid match?
There's no fixed number that works everywhere — it depends on how similar your library images are to each other and how costly a false positive is for your workflow. Start conservative, review a sample of borderline results, and adjust the threshold based on where you actually see incorrect matches slipping through or good matches getting rejected.
Does the user's photo need to be hosted online first?
No. You can send it directly as base64-encoded bytes through the 'images' field, which is the usual path for a photo a user just uploaded from their device. If the photo already lives at a public https URL, you can pass that URL instead — either works, but not both in the same request.
What happens if there's genuinely no match in my library?
The nearest-neighbour lookup will still return the closest vector it can find, because similarity search always returns something. That's exactly why the confidence threshold exists on your side — below your chosen threshold, treat the result as no match, since a low similarity score for the 'best available' candidate is not the same thing as a real match.
When is reverse image search the wrong tool?
It won't tell you if two images are pixel-for-pixel identical — that's a job for file hashing, not embeddings. It also doesn't read text baked into an image, count or localise multiple objects within a frame, or verify authenticity or ownership; it only reports visual similarity to what's already in your indexed library, so it's not a substitute for a proper rights-management or OCR system.

Other use cases

Ready to try it?

Start a 14-day free trial on any paid plan. No credit card required.

Start free trial