How accurate is visual search compared to a normal text search box?

It answers a different question. Text search matches what a shopper types against your titles and tags; visual search matches what a photo actually looks like against your product images. DINOv3 has no concept of price, size, or brand, so visual search works best layered alongside your existing search and filters rather than replacing them outright.

Do I need to re-embed my entire catalogue every time I add a product?

No. Embed each new or changed product photo once, when it's added or replaced, and append it to your existing index. There is no need to reprocess SKUs that haven't changed — the credit cost scales with catalogue churn, not catalogue size.

Where do the embedding vectors actually get stored?

Wherever you put them. Webanto's API returns the vector and does not retain or index it, so you're responsible for storage and search — typically pgvector inside an existing Postgres database, or a dedicated vector database like Pinecone if you need managed scaling.

What kind of product photos work best for this?

Clean, well-lit, front-facing shots with the product as the dominant subject work best. Heavy watermarking, busy lifestyle backgrounds, or collage-style images with multiple products in one frame reduce match quality because DINOv3 is embedding the whole frame, not a cropped product region.

When does visual search not make sense?

Skip it for very small catalogues (a few hundred SKUs or fewer), where filters and a decent text search already find everything quickly enough that a separate embedding pipeline is not worth maintaining. It's also a poor fit for catalogues of visually near-identical items — plain capsules, blank labels, uniform packaging — where DINOv3 has little visual signal to discriminate on.

USE CASE

Let shoppers search your catalogue with a photo

Use case: Visual product search from a shopper's own photo

Shoppers who spot a product in the wild, on someone else's feed, or on a competitor's site rarely know the right keywords to find it in your catalogue. Visual search closes that gap: a shopper uploads or snaps a photo, Webanto embeds it with DINOv3, and the resulting 1280-dimensional vector is compared against the pre-embedded vectors for every SKU in your catalogue to surface the closest visual matches. DINOv3 responds to shape, colour, texture, and composition rather than metadata, so it finds the pale-blue linen jacket a shopper photographed at a friend's house even when the product title says nothing about colour or fabric. The vectors themselves are stateless outputs — Webanto never stores or indexes them, so your product-to-vector mapping and the nearest-neighbour search both live in infrastructure you control.

What to expect

Shoppers can find items using a reference photo instead of guessing keywords, which is a documented driver of visual-search adoption in ecommerce generally.
A single embedding call per catalogue image means the recurring cost is just the query-time embedding for each shopper photo, not a per-search licensing fee.
Matches are driven by the item's actual visual attributes, so near-identical products from different suppliers surface together even with inconsistent titles.
The nearest-neighbour index is entirely yours, so you can combine it with in-stock and pricing filters however your storefront already works.

How to set this up

1
Export one clean, front-facing photo per SKU from your product catalogue, keeping each SKU's identifier attached to its image URL or file.
2
Batch the images to POST /api/v1/image-embeddings, at most 60 per call, and store the returned 1280-dimensional vector against its SKU id in your own database or vector store (pgvector, Pinecone, or similar — Webanto does not persist vectors).
3
For a 40,000-SKU catalogue that's 40,000 images divided by 20 per credit = 2,000 credits for the initial index, well inside a single month on the Growth plan (50,000 credits/mo, $79).
4
Build a nearest-neighbour index over the stored vectors (an IVFFlat or HNSW index in pgvector, or a Pinecone index) so lookups stay fast as the catalogue grows.
5
On the storefront, accept a shopper-uploaded or camera photo, send that single image to the same embedding endpoint, and query your index with the resulting vector.
6
Join the returned SKU ids against live inventory and pricing before rendering results — the embedding carries no stock or price information, only visual similarity.
7
Re-embed new or replaced product photos as they're uploaded rather than reprocessing the whole catalogue, so ongoing credit spend tracks catalogue churn, not catalogue size.

Products that power this use case

Webanto AI API

Frequently asked questions

How accurate is visual search compared to a normal text search box?
It answers a different question. Text search matches what a shopper types against your titles and tags; visual search matches what a photo actually looks like against your product images. DINOv3 has no concept of price, size, or brand, so visual search works best layered alongside your existing search and filters rather than replacing them outright.
Do I need to re-embed my entire catalogue every time I add a product?
No. Embed each new or changed product photo once, when it's added or replaced, and append it to your existing index. There is no need to reprocess SKUs that haven't changed — the credit cost scales with catalogue churn, not catalogue size.
Where do the embedding vectors actually get stored?
Wherever you put them. Webanto's API returns the vector and does not retain or index it, so you're responsible for storage and search — typically pgvector inside an existing Postgres database, or a dedicated vector database like Pinecone if you need managed scaling.
What kind of product photos work best for this?
Clean, well-lit, front-facing shots with the product as the dominant subject work best. Heavy watermarking, busy lifestyle backgrounds, or collage-style images with multiple products in one frame reduce match quality because DINOv3 is embedding the whole frame, not a cropped product region.
When does visual search not make sense?
Skip it for very small catalogues (a few hundred SKUs or fewer), where filters and a decent text search already find everything quickly enough that a separate embedding pipeline is not worth maintaining. It's also a poor fit for catalogues of visually near-identical items — plain capsules, blank labels, uniform packaging — where DINOv3 has little visual signal to discriminate on.

Other use cases

Ready to try it?

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

Start free trial