Adding 3d to client websites a designer adding 3d to client websites's Guide to Getting the Files Right

Last month a client sent me an email with the subject line “quick question,” which it never is. Inside was a link to a competitor’s product page where the sneaker spins in 3D. She wanted hers spinning too, and her budget for it was, and I quote, “it can’t cost much, right?” I design websites. Modeling is not a thing I do, and that budget had no room for anyone who does it professionally.

A couple of years back I would have gently talked her out of the whole idea. This time I said yes, because somewhere along the way the hard part of putting 3D on a website stopped being the 3D itself. What actually eats your afternoon now is the file handling, and that part nobody bothers to explain to designers. So here is the explanation.

The web picked its format, and it is GLB

Every serious way of putting 3D on a website today runs on glTF, usually in its binary form, GLB. Google’s model-viewer component wants it. Three.js loads it best. Design tools like Spline export it. Your phone’s AR viewer speaks it too, or something close enough. Why did this one win? Because a GLB is a single compact file with everything baked inside it, and it was built for fast loading over a network instead of for editing in a studio. The web rewards exactly that.

So the destination is settled. If a model is going on a page you are building, it needs to end up as a GLB. The problem is where models actually come from.

Clients do not have GLBs. They have whatever their vendor sent.

Ask a client for their product’s 3D file and you will receive one of three things. An FBX, because their manufacturer or product visualization studio works in tools where FBX is the native tongue. An OBJ, usually exported years ago by someone who no longer works there. Or a CAD file so raw that it needs professional help before it needs you.

The first two are completely workable, and this is the part that surprises designers: converting them is now a browser task. I run FBX and OBJ files through this free browser converter and get a web-ready GLB back in under a minute, with the scale intact, which matters more than any other single property. A product that renders at the wrong size in an AR view is not a small bug. It is a customer holding their phone up to their desk and seeing a sofa the size of a shoebox.

The alternative route is Blender, which is free, powerful and complete overkill for this job. It is a 300MB install and a genuinely steep learning curve, and if your entire 3D need is “turn the client’s file into the right file,” you do not need it. If your projects grow into editing models, retopology or custom materials, that is the moment to learn it. Not before.

Four things to check before the file goes near a page

  • Scale. Open the converted GLB in any viewer and sanity-check the dimensions. Format conversions between centimeter-based and millimeter-based tools are where size bugs are born.
  • Textures. If the model arrives gray, the textures did not make the trip. With OBJ sources this usually means the separate material file was missing from what the client sent. Ask for the full export folder, not just the one file.
  • Orientation. Some tools treat Y as up and others prefer Z, so a converted model occasionally lies face-down. One rotation fixes it, but check before you embed, not after the client does.
  • Weight. This is the one designers are actually well equipped for, because it is a performance budget question. A product model for the web should live in the low single-digit megabytes. If the file is 40MB, it was made for rendering, not for browsers, and it needs compression before it ships.

On weight, because it will decide whether the feature survives

Here is the uncomfortable truth about web 3D: the spinning sneaker gets approved in the design review and then dies in the performance review. A heavy model drags Largest Contentful Paint, mobile users on weak connections stare at a loading spinner, and three months later someone quietly replaces your viewer with a JPEG.

You prevent that the same way you prevent it with images. Two moves cover most of it. The first is Draco compression on the geometry, which most GLB tooling supports. One of my client files went from 22MB to under 8 with a single pass. The second is texture resizing, and this one hurts to see done wrong, because a 4K texture wrapped around a product that renders 400 pixels wide is pure waste. If you want a bonus third move, defer loading the viewer until the user actually scrolls near it. You already apply this whole mindset to hero images. Same discipline, new file type.

Embedding is the easy part

Once you hold a clean, sensibly sized GLB, the finish line is close. Google’s model-viewer is a single script tag and a custom element, and it handles rotation, zoom, lighting and AR handoff with sane defaults. For more designed experiences, Spline and three.js both take your GLB and give you as much control as you want to claim. The point is that every one of these tools assumes you show up with the right file. That assumption is the entire game.

The clients asking for 3D this year are not early adopters anymore. They are ordinary businesses copying what they saw on a bigger competitor’s site, which means this request is coming to every designer’s inbox eventually. The designers who say yes will not be the ones who learned modeling. They will be the ones who learned the twenty-minute pipeline: convert the client’s file, check four things, compress, embed. That pipeline is the whole skill, and now you have it.

My client’s product spins now, by the way. She thinks I hired someone. I have not corrected her.

3D Related Articles & Resources


Pinterest