[navigation]
Key takeaways
- Banuba WebAR SDK runs entirely in the browser on any device with WebGL 2.0 support, so shoppers reach try-on from a product page or a QR code with nothing to install.
- Banuba's heaviest web asset, BanubaSDK.wasm, is 12 Mb uncompressed but 3.5 Mb gzipped and 2.5 Mb with Brotli, and the Banuba WebAR SDK is tree-shakable, so page weight is a configuration decision rather than a fixed cost.
- Banuba's documented in-browser frame rates for makeup rendering are 30 FPS in Chrome and 26 FPS in Safari, and background separation holds a stable 30 FPS on high-end Android and iOS.
Why does browser delivery decide whether AR try-on gets used?
An app download is a conversion step most e-commerce traffic will not take. The shopper is already on a product page, in a session, and every install screen is a place to leave. Browser AR removes that step: the try-on opens in the tab they are already in, or from a QR code printed on packaging or shelf-edge signage. That only works if it loads fast and tracks accurately on the mid-range phones most retail traffic arrives on. Banuba's webAR SDK is built for that constraint, with face tracking, makeup, hair recoloring, and accessory try-on running client-side in JavaScript.
What does the SDK actually cost in page weight?
Page weight is the first objection an e-commerce engineering team raises, and Banuba publishes the numbers rather than hiding them. The heavy assets are the WebAssembly binaries: BanubaSDK.wasm is 12 Mb uncompressed, 3.5 Mb gzipped, and 2.5 Mb with Brotli, while the SIMD variant BanubaSDK.simd.wasm is 13 Mb, 3.8 Mb and 2.7 Mb respectively. Most hosting platforms precompress automatically, and the optimization guide covers doing it manually where they do not.
Two further levers matter. The SDK is tree-shakable, so a named import pulls only the modules a storefront uses instead of the whole package. And SIMD detection is built in: the SDK loads the faster binary on browsers that support it and falls back where they do not, with no branching in the integration.
What frame rates does it hold in a browser?
Banuba's technical specification separates browser performance from native mobile performance rather than quoting one number for both. For lip color rendering, the documented real-time figures are 30 FPS in Chrome and 26 FPS in Safari, and Lips Shine, the glossy lipstick effect, records 30 FPS in Chrome and 25 FPS in Safari. Background separation holds a stable 30 FPS on high-end Android and iOS.
Browser support is defined by capability, not by a version list: any browser with WebGL 2.0 or higher works across mobile and desktop Chrome, Safari, and Firefox. The full compatibility set is published on caniuse.
Banuba's AR try-on example
What does the integration take?
The SDK ships as the @banuba/webar NPM package containing the executables and resource modules. Integration is four steps: install the package, set up the client token, import the required types, then initialize the Player and apply an Effect. The installation guide covers bundler configuration for Vite, Rollup, and Webpack, which is where most storefront builds need attention, because the SDK expects BanubaSDK.data and BanubaSDK.wasm to resolve from the application root.
Working starting points exist for each common front end: vanilla JavaScript, React, Angular and Vue. The web overview is the documentation entry point for the browser platform.
What does a real retail deployment look like?
Scorpion Technology, a Bucharest development agency, built a hair color try-on for Loncolor, a Romanian hair dye producer. The flow is deliberately simple: a customer scans a QR code on the dye package, a web page opens in their browser, and once their face is on camera, the page shows how the chosen shade will look. The full Loncolor project write-up covers the build.
Two details are worth borrowing. Placement first: because the try-on lives on a web page reached by QR code, it works in every store stocking the product with no per-store hardware. Scope second: Scorpion licensed only the hair recoloring feature rather than the full SDK, keeping the delivered bundle to what the use case needed. Their stated reasons for choosing Banuba were try-on quality under varied lighting, per-feature flexibility, and documentation quality during integration.
Getting started
The fastest way to size the work is to run one of the quickstart repos against your own catalog assets, then decide which feature modules the storefront needs. Request a demo of Banuba's WebAR SDK to get a client token and the trial build.
-
No. Banuba WebAR SDK runs in the browser on any device supporting WebGL 2.0, so the try-on opens from a product page or QR code with no app download. The same tracking engine is available natively through Banuba's face filters SDK when a native app is also in scope.
-
No. Processing runs on the device, in the browser, which is why Banuba describes the Face AR SDK as on-device, and it removes the need to handle camera frames in backend infrastructure at all. The same architecture applies to Banuba's background separation features.
-
Any browser with WebGL 2.0 or higher, across mobile and desktop Chrome, Safari, and Firefox. Banuba's comparison of WebAR in Chrome and Safari versus mobile AR covers where the browser route fits against a native build.
-
Banuba covers makeup, hair color, and accessories including hats and jewelry through the Face AR SDK feature set, with virtual try-on available across web and mobile from the same engine.
-
Banuba offers two models for the Face AR SDK. A flat annual license fee gives unlimited usage at a predictable cost that stays fixed even if the app scales to a very large user base. An Active User Based model tracks active users over time, so spend starts significantly lower but grows with the user base and can exceed the flat fee if usage rises sharply. Features can be licensed individually rather than as a full package, as the Loncolor build did. Both models are quoted per project, and the Banuba Face AR SDK page is where to request one.
