GeometryViewer vs Google model-viewer — When to Use Which

Two Tools, Different Goals

Google's <model-viewer> is a well-engineered open-source web component backed by the Google Chrome team. It's been around since 2018, has a large community, excellent documentation, and is the de facto standard for displaying GLB and GLTF models on the web. If you search "embed 3D model in website," most results will point you to model-viewer.

GeometryViewer's <geometry-viewer> was built for a different audience. While model-viewer targets web developers building polished e-commerce and marketing experiences, GeometryViewer targets people who need to quickly view and share 3D files in various formats — engineers, designers, 3D printing enthusiasts, architects, and anyone who works with CAD files. The goals overlap, but the priorities are different.

This article is not going to declare a winner. Both tools are good at what they do. The goal is to help you choose the right one for your specific situation, and to be honest about the trade-offs in each direction.

Format Support

This is the biggest differentiator. Google model-viewer supports GLB and GLTF only. That's it. If your 3D file is in any other format, you need to convert it to GLB before model-viewer can display it.

GeometryViewer supports GLB, GLTF, STL, OBJ, 3MF, and STEP. The format conversion happens automatically on the fly — you upload an STL, and the viewer displays it. No preprocessing step, no external conversion tool, no pipeline to maintain.

If you're in a web development context where your 3D assets are already in GLB format (which is increasingly common for e-commerce and marketing), this difference doesn't matter. Your models are already in the right format for model-viewer.

But if you're in an engineering, manufacturing, or 3D printing context, you're probably working with STL, OBJ, STEP, or 3MF files. Converting these to GLB is possible but adds friction: you need to install conversion tools (like Blender or online converters), material information may not transfer perfectly, and you now have two versions of every file to manage. GeometryViewer eliminates this conversion step entirely.

Setup Complexity

Google model-viewer can be loaded from a CDN (unpkg or the Google CDN) or installed via npm. The CDN approach is straightforward:

<script type="module" src="https://unpkg.com/@google/model-viewer/dist/model-viewer.min.js"></script>
<model-viewer src="/model.glb" camera-controls auto-rotate></model-viewer>

GeometryViewer's setup is essentially identical:

<script type="module" src="https://geometryviewer.com/embed.js"></script>
<geometry-viewer src="/model.stl" camera-controls auto-rotate></geometry-viewer>

Both approaches are two lines of code. The setup complexity is equivalent for basic use cases. Where things diverge is in the npm workflow.

If you're building a production web application and want to bundle model-viewer into your build pipeline, you install it via npm: npm install @google/model-viewer. This gives you tree-shaking, TypeScript types, and integration with bundlers like Vite, Webpack, or Rollup. The npm package is well-maintained and follows semantic versioning.

GeometryViewer doesn't currently offer an npm package. It's designed to be loaded from the CDN. For many use cases — landing pages, blogs, documentation sites, no-code builders — this is perfectly fine. For large web applications where you want to control every dependency, the CDN-only approach may feel less rigorous. That said, the CDN-loaded script is small and cached aggressively, so the practical difference in user experience is negligible.

AR Support

This is where Google model-viewer really shines, and it's not close. Model-viewer has the best AR integration of any web-based 3D viewer. It supports WebXR for Android devices, Scene Viewer as a fallback for older Android, and AR Quick Look for iOS. The AR experience is seamless — users tap a button, and the model appears in their physical space through their phone's camera.

Model-viewer also handles the USDZ conversion needed for AR Quick Look on iOS. You can provide a separate ios-src attribute with a USDZ file, and model-viewer will use it for the iOS AR experience while using the GLB file for the web viewer. This dual-format approach gives you the best AR quality on both platforms.

GeometryViewer supports AR through the ar attribute, but the implementation is simpler. It uses the browser's built-in WebXR capabilities and falls back to Scene Viewer on Android. iOS AR Quick Look support requires a USDZ file, which GeometryViewer can link to but doesn't auto-convert from GLB. If AR is your primary use case — like an e-commerce site where customers "try before they buy" — model-viewer is the better choice.

Rendering Quality

Both viewers use WebGL for rendering and produce high-quality output. Model-viewer uses Three.js internally and has been fine-tuned for physically-based rendering (PBR). It handles metallic, roughness, clearcoat, and transmission materials accurately, making it excellent for product visualization where material fidelity matters.

Model-viewer also supports environment maps (HDR lighting), dynamic shadows, and tone mapping out of the box. These features make models look photorealistic when the materials are properly configured. Google has invested significant effort in making model-viewer's default rendering competitive with dedicated 3D rendering software.

GeometryViewer's rendering is optimized for clarity rather than photorealism. It renders STL files with clean, uniform lighting that shows geometry clearly — important for engineering and CAD review where you need to see surface details, not artistic lighting effects. For GLB files with PBR materials, GeometryViewer renders them faithfully, but model-viewer has more advanced material support (transmission, clearcoat, emissive).

If your model has complex materials (glass, chrome, translucent plastic) and you need them to look their best, model-viewer handles these edge cases better. If your model is a CAD part, a 3D print, or a simple textured mesh, both viewers look equally good.

Customization and API

Model-viewer has a rich JavaScript API. You can programmatically control the camera, swap materials at runtime, add hotspots (clickable annotations on the model), animate between camera positions, and respond to user interactions. The API surface is large and well-documented, making model-viewer suitable for complex interactive experiences like product configurators.

GeometryViewer's API is simpler. You set attributes on the element — src, camera-controls, auto-rotate, ar — and the viewer handles the rest. There's event support for load, error, and progress, and you can update attributes dynamically with JavaScript. But there's no hotspot system, no programmatic camera animation, and no runtime material swapping.

This simplicity is intentional. A simpler API means less to learn, fewer things that can break, and faster integration. If you need a viewer that just works with minimal configuration, the simpler API is an advantage. If you need a viewer that's a building block for a complex interactive application, model-viewer's richer API is necessary.

Hosting and Sharing

This is an area where GeometryViewer offers something model-viewer doesn't: a hosting platform. When you upload a model to GeometryViewer, you get a shareable URL. You can send that URL to anyone — they don't need an account, and they view the model in their browser instantly. This URL can also be used as the src for the web component embed.

Model-viewer is a pure web component — it doesn't host files. You need to host your GLB files yourself (on your own server, S3, Cloudflare R2, or another CDN) and point model-viewer's src attribute at the URL. This is fine for developers who already have hosting infrastructure, but it's an extra step for designers, engineers, or non-technical users who just want to share a 3D file.

For teams where non-developers need to share 3D models — sending a link to a client, embedding in a Notion doc, posting in a Slack thread — GeometryViewer's hosted viewer is significantly more convenient than setting up file hosting and configuring model-viewer.

Bundle Size and Performance

Model-viewer's npm package (minified, gzipped) is approximately 130 KB. This includes Three.js internals, the AR modules, and the web component registration. If you load it from the CDN, the browser caches it after the first load, so repeat visitors don't pay the download cost again.

GeometryViewer's embed script (from CDN, gzipped) is under 20 KB. The smaller size is partly because it doesn't include model-viewer's extensive AR module and partly because the rendering engine is lighter. For pages where bundle size matters — landing pages, blogs, documentation — this difference is meaningful.

However, both tools load the actual 3D model data on top of the script size. A 5 MB GLB file is 5 MB regardless of which viewer loads it. The model file size typically dwarfs the viewer script size, so the script difference matters most when the model is very small or when you're optimizing aggressively for first load.

The Honest Recommendation

Choose Google model-viewer if:

• Your models are already in GLB/GLTF format
• AR is a primary feature of your product
• You need hotspots, annotations, or programmatic camera control
• You're building a product configurator or interactive 3D experience
• You want npm integration with semantic versioning
• Your models have complex PBR materials (glass, chrome, transmission)

Choose GeometryViewer if:

• You work with STL, OBJ, 3MF, or STEP files
• You need to share models via links without setting up hosting
• You want the simplest possible embed with the smallest script size
• You're embedding in a no-code builder (Squarespace, Wix, Webflow, Notion)
• You need non-technical team members to view and share models
• You want format-agnostic viewing without a conversion pipeline

And here's the thing many comparison articles won't tell you: you can use both. On a Shopify product page, you might use model-viewer for the hero product viewer with AR support, and link to GeometryViewer for the engineering drawings and STL downloads. Different tools for different parts of the workflow.