Full-Look Virtual Try-On: How to Build an Entire Routine in the Browser

Most virtual try-on projects start with a single product — almost always lipstick or foundation. It makes sense: it is the most frequent shade question and the easiest palette to map. But the customer does not buy an isolated item, they buy a combination. That is where full-look virtual try-on comes in: instead of testing a lipstick on a bare face, the person builds the whole routine and sees how the pieces work together.

This article explains what the full look actually delivers, where it changes the commercial conversation and what your team needs to have ready before integrating.

What a full look is, in practice

In the MaIA Try-On browser SDK — in early access since September 2026 — thirteen products are available: lipstick, foundation, blush, face powder, under-eye concealer, eyeshadow, mascara, eyebrow makeup, eyeliner, bronzer, contour, highlighter and lip liner. On top of those there is the Full Look, which applies the combination in a single render.

Why the combination matters

A red lipstick on a bare face and the same lipstick on a face with foundation, contour and neutral eyeshadow do not read the same way. Someone testing an isolated item is evaluating the product outside the context in which they will wear it. The full look brings the test closer to real use and, with that, makes the purchase decision less risky — for the consumer and for the CRM team that will answer the exchange e-mail afterwards.

For the brand, there is an additional effect: the basket stops being one product and becomes a set. Whoever builds a look on screen is, in practice, building a cart.

Any #RRGGBB colour

The SDK accepts any colour in hexadecimal. That means the palette does not need to wait for an external calibration cycle to go live: the product team enters the values it already uses in the catalog and tests. For large palettes or seasonal launches, that autonomy is often the factor that decides between publishing in the week of the campaign or the following month.

Full-look virtual try-on: live mode or photo mode

The SDK runs in both modes, and they serve different moments of the journey.

Live camera mode. Rendering happens locally in the user's browser — nothing is sent to a server. It is the mode with the least privacy friction, because there is no image upload, and the most natural for someone who wants to move their head, check angles and switch colours quickly. It works well on the product page, on a campaign landing page and on an in-store kiosk with a browser.

Photo mode. The person uses a photo of themselves and sees the look applied to it. It is useful when the customer wants to save, compare side by side or send it to someone before deciding. It is also the mode that holds up best in poor lighting, because the person chooses the image.

If the question is which approach suits your channel, it is worth reading the comparison between photo-based virtual try-on and the market alternatives before closing the scope.

An important distinction of scope

The thirteen products and the Full Look are browser SDK features, with local preview. The MaIA Try-On API is photo-based and renders lipstick and foundation, with palettes calibrated to the brand's real products within a project. They are different paths for different problems: the API serves server-side flows, messaging and automations; the SDK serves the interactive experience inside your site. Mixing the two promises in the brief is the most common source of frustration at kickoff.

Three scenarios where the full look pays for the integration

Collection launch

A collection is rarely sold item by item in the communication. The campaign shows a look. If the page lets people reproduce that look on their own face, the distance between the ad and the cart shrinks — and the marketing team gains an asset that works in paid, organic and CRM.

Kits and bundled baskets

When the brand sells a kit, the obstacle is imagining the set. A pre-built Full Look, with the kit's items already applied, turns a list of SKUs into a single image.

Customer service and consultation

The in-store sales assistant or the chat agent can build the look together with the customer, instead of describing it. The conversation stops being about shade names and becomes about what the person is seeing.

What to prepare before requesting access

The SDK is self-hosted by the brand and early access is granted per account — there is no public download and no promised device certification. Before opening the conversation, three fronts help:

1. Mapped catalog. Each SKU needs a reliable hexadecimal value and a category among the thirteen products. Without that, the full look becomes a generic simulator.
2. Curated looks. Someone from the product or makeup team needs to define the initial combinations. Leaving the user to build everything from scratch leads to abandonment.
3. Data plan. What you will record from each session, and on which legal basis. Live mode sends no image, which simplifies the privacy conversation a great deal, but colour choices are still business data.

Where the beauty profile comes in

Try-on answers "how does it look on me". It does not answer "what should I wear". That is what selfie skin and hair analysis is for: it returns tone, undertone, skin type and condition as JSON, with per-field confidence — visible attributes from a photo; it is not a clinical assessment and does not replace a health professional. Combining the two is what makes it possible to open the full look with the foundation already in the likely shade, instead of the first colour on the list.

Start with what you can already test today: create your account, generate the API key and run skin analysis and photo-based virtual try-on. If your case is the full look in the browser, talk to the team to assess early access to the SDK.