Virtual Try-On Without Photo Upload: How Live Mode Works in the Browser

In almost every virtual try-on project there is a meeting where someone from legal or security asks the same question: where does the customer's photo go? The answer defines the timeline, the contract and, very often, whether the project gets off the ground at all. That is why virtual try-on without photo upload has stopped being a technical detail and become a decision criterion — especially for brands that serve end consumers in Brazil and need to explain, in plain language, what happens to the image.

This article separates two paths that are often confused: local rendering in the browser and photo-based processing through the API. Both are legitimate, solve different problems and can coexist in the same e-commerce store.

What "no upload" really means

"No upload" does not mean no data exists. It means the camera frame does not leave the customer's device to be processed on a server. Working out where the lips, eyelids and cheekbones are, and applying the chosen colour, happens in the browser itself.

That changes three internal conversations at once:

• Legal: no face image is transferred to a third party to generate the preview.
• Security: there is no new photo repository to protect, version and purge.
• Product: the customer does not have to accept a long terms screen before trying a lipstick, which reduces friction in the first interaction.

Honesty matters here: the experience still happens inside your site, so your privacy policy and your consent banner still apply. What disappears is the step of sending and storing the image somewhere else.

Virtual try-on without photo upload: how the SDK works in the browser

MaIA Try-On comes in two forms, and only one of them does away with sending the image.

Live camera mode

The browser SDK, in early access since September 2026, is hosted by the brand itself and runs in the customer's browser. In live mode, the camera opens, rendering happens locally and nothing is sent. Thirteen products are available — lipstick, foundation, blush, face powder, under-eye concealer, eyeshadow, mascara, eyebrow makeup, eyeliner, bronzer, contour, highlighter and lip liner — plus a Full Look that combines the items into a single look. Any colour in #RRGGBB format can be applied, which lets you mirror your real catalog, including launches and limited editions.

There is also a Photo mode, for the customer who prefers to use an existing image instead of opening the camera.

Because the SDK is self-hosted, the file runs on your infrastructure and within your domain. There is no public download: access is granted per account, case by case, because we are still in early access.

The photo-based path, through the API

The MaIA Try-On API works differently: the brand sends a photo, the product is rendered onto it and the image comes back ready. Here, by definition, an image is sent — and that is exactly what makes the API useful in channels where there is no browser with a camera, such as WhatsApp, e-mail, campaigns and CRM flows. The API covers lipstick and foundation, with palettes calibrated to the brand's real products within a project. The other eleven products and the Full Look are exclusive to the SDK, as a local preview.

If the question is which of the two formats fits your channel, the comparison between photo-based try-on and real-time try-on details the differences in experience and integration.

When live mode is the right choice

Product page with high mobile traffic. The customer is deciding on a shade on their phone, camera at hand. Opening, testing and closing in seconds, with no upload consent screen, reduces abandonment at the most sensitive moment of the journey.

Colour categories with many variations. Eyeshadow, blush, contour and highlighter gain little in a static image and a lot in motion, with the customer turning their face and seeing the result under their own lighting.

Brands with a restrictive data policy. Groups with a strong compliance function, or that also serve corporate customers, tend to approve a local preview with far less friction than a pipeline that sends faces out.

When the photo-based path still wins

Channels without a browser. In a WhatsApp conversation, there is no SDK running. The API solves it: the customer sends a selfie and receives the image with the lipstick applied.

Content generated in bulk. Campaigns, segmented e-mails and launch pages can use the API to produce previews server-side, without depending on the customer's session.

When the preview is only the beginning. If the intention is to go beyond "that looks nice" and reach "this is your foundation", the preview needs context. That is where selfie skin and hair analysis comes in: skin tone and undertone, skin type and condition, hair attributes and a per-field confidence, returned as JSON. That profile can feed recommendations, CRM and the beauty advisor integrated with your catalog.

An important reminder: the analysis describes visible attributes from a photo. It is not a clinical assessment and does not replace a health professional, and it should not be communicated as such.

Checklist before deciding

1. Map the channel. Your own site with a camera? SDK. WhatsApp, e-mail, third-party app? API.
2. Talk to legal before design. Knowing whether the preview is local changes the consent wording and the scope of the contract.
3. Prepare the catalog in hex. The SDK accepts any #RRGGBB; the quality of the result depends on colours faithful to the real products.
4. Decide what you want to keep. A local preview does not generate first-party data on its own. If you want data, it is the beauty profile — with explicit consent — that comes into play.
5. Plan the fallback. Not every customer allows camera access. Having Photo mode, or an API-based flow, avoids a dead end.

Want to test both paths on your catalog? Create an account and generate your API key in the documentation — or talk to our team to assess early access to the browser SDK for your brand.