Industries / E-commerce

3D product visualization for e-commerce with Three.js

Let a shopper rotate, zoom and configure the product in the browser instead of clicking through photos, on your storefront rather than in a hosted viewer.

  • 01Viewers, configurators and 360 views
  • 02AR on iOS and Android
  • 03Works with any storefront
  • 04You control the performance
3D product page with material variants, colour options, 360 view and AR preview

3D product visualization lets a shopper rotate, zoom and configure a product in the browser instead of clicking through photos. Three.js is the standard way to build it on the web because it runs everywhere without a plugin, integrates with any storefront, and stays under the control of the store rather than a hosted viewer vendor.

3D product viewers, configurators and 360 views

Five things account for nearly every e-commerce 3D brief. They share a pipeline, so a store that builds one can usually add the next without starting again.

Build[01]

Interactive product viewer

The product as a model the shopper turns, zooms and inspects, loaded as a glTF or GLB. Start from the GLB viewer to check an asset, and the GLTFLoader guide for the loading and Draco setup that keeps it fast.

Build[02]

Product configurator

Materials, colours, components and sizes, changing in real time with the price following the selection. It is the most valuable thing on this list and has its own page.

Build[03]

360 product view

Two different things share this name. A photo 360 is a ring of real photographs, which looks perfect and cannot be configured. A true 3D 360 is a model, which can be relit, recoloured and placed in AR. Photos win for a single finished product you already photographed; 3D wins the moment there is more than one version of it.

Build[04]

Virtual try-on and AR

Placing the product in the buyer's room or on their wrist, through WebXR on Android and AR Quick Look on iOS, from the same source asset. See the WebXR pages for what each platform supports today.

Build[05]

Visualization from CAD data

The product already exists as a CAD file, and the web needs a much lighter version of it. That conversion is its own discipline: see model optimization for the pipeline and what it costs in fidelity.

See it live

Production e-commerce work from the showcase. Open one and read the breakdown to see the stack behind it.

All e-commerce showcase entries
[Proof]

See it in production

Browse the full showcase →

Tools and libraries

The loaders, viewers and helpers worth knowing before writing your own. Everything here is in the directory with the licence and maintenance status.

Browse the directory
[Stack]

Build it yourself

The fastest route is to start from something that already handles variants, URL state and AR export rather than assembling it.

For the shader and material side, the TSL and WebGPU course covers node materials, which is what makes a configurator's finishes look like the real product rather than like plastic.

See the courses
[DIY]

Performance and mobile

Product 3D fails on phones for four reasons, in this order. None of them show up on a desktop with a discrete GPU, which is why they survive until launch.

[Budget]
Fix[01]

Texture weight, not polygon count

A single 2048px texture set can occupy more GPU memory than the entire mesh. Compress to KTX2 and size textures to how large the product actually appears on screen.

Fix[02]

One product, one draw call

A CAD export arrives as hundreds of parts. Merge everything that shares a material, and keep parts separate only where the configurator needs to address them.

Fix[03]

Load order

Show a lit, low-detail version immediately and stream the rest. A blank canvas while 12 MB downloads is a bounce, not a load time.

Fix[04]

Memory on mid-range phones

Dispose geometries and textures when a variant is swapped out. Configurators leak memory faster than anything else on this list because they load assets repeatedly.

The full pipeline, and what each step costs in fidelity, is on the model optimization page.

Alternatives, and when not to use Three.js

Google model-viewer is a web component that shows a GLB with AR in about five lines. If you need one product spinning on a page, use it. It is not built for configuration, custom materials or your own UI.

Hosted configurator SaaS such as Threekit, Zakeke or Expivi gets you running in weeks with no engineering, at a monthly fee, inside their feature set. That trade is worth it until the catalogue or the visual bar outgrows what the platform allows.

Shopify's native 3D handles a GLB and USDZ per product with AR built in. It is the right answer for a small catalogue that needs no configuration.

Three.js is the choice when the product has variants, when the material quality is part of the brand, when the viewer has to live inside your own interface, or when performance on a mid-range phone is something you need to control rather than hope for.

[Honest]

Get it built

Scope and quote after a short call. Every job gets a written scope with acceptance criteria before a number, because product 3D estimates go wrong when the variant count is assumed rather than counted.

[Next step]

For brands and stores

I scope, build and ship the work myself: viewers, configurators and the asset pipeline behind them.

Product visualization →

For agencies

The same work as a white-label subcontractor, invoiced to the agency, delivered under your brand.

White-label configurators →

Not ready to build

A review of the approach, a performance diagnosis, or a second opinion on a quote that arrived.

Consulting →

F.A.Q

Frequently Asked Questions.

What store owners and developers ask before starting.

The basics

What it is and whether it pays.

It is showing a product as an interactive 3D model in the browser rather than as a set of photographs. The shopper can rotate it, zoom in, change materials and colours, and in many cases place it in their own room through AR. The model is rendered live, so one asset covers every angle and every variant.

Vendors publish large numbers here and most of them are self-reported, so treat them carefully. What is consistent across studies is that 3D and AR help most where the buyer has a real question a photo cannot answer: scale, fit, finish, or how a configuration looks.

Building it

Platforms, assets and limits.

Yes. Shopify supports GLB and USDZ models natively on product pages, which is enough for a single spinning product with AR. Once you need configuration, custom materials, price logic or your own UI, you are building a Three.js viewer and embedding it in the theme instead.

Smaller than most exports arrive at. Aim for a total download in the low single-digit megabytes with KTX2 textures and Draco or Meshopt geometry, and test on a mid-range Android rather than a desktop.

Photos if the product is finished, already photographed, and has one version. Real 3D if there is more than one configuration, if it needs AR, if it does not physically exist yet, or if you want to change the lighting without a reshoot.

Last updated 2026-09-10