Online3DViewer: a browser-based 3D model viewer and its npm engine

What Online3DViewer solves, and who it is for

Getting a 3D file open is a recurring annoyance. A STEP file from a supplier, an STL from a colleague, an FBX exported from a modelling tool: each format tends to want its own desktop application, and often its own licence. Online3DViewer takes the opposite approach. The README describes it as a free and open source web solution to visualize and explore 3D models in your browser, and the repository contains both the source of the website at 3dviewer.net and the library behind it.

The audience is therefore two groups. The first is people who simply need to look at a model: engineers reviewing a part, designers checking a mesh, anyone who received a file and does not want to install anything. The second group is developers who want that viewing capability inside their own product. The npm package online-3d-viewer exists for them, with its main entry pointing at build/engine/o3dv.module.js. The project is written in JavaScript and published under the MIT licence.

Import and export formats the viewer actually handles

Format coverage is the main reason to pick this project over a generic WebGL demo, so it is worth reading the list carefully. According to the README, import supports 3dm, 3ds, 3mf, amf, bim, brep, dae, fbx, fcstd, gltf, ifc, iges, step, stl, obj, off, ply and wrl. Export supports a shorter set: 3dm, bim, gltf, obj, off, stl and ply.

The asymmetry matters. A STEP or IGES file can be opened and inspected, but it cannot be written back out in its original format; the export list does not include step or iges. If your workflow is view-only, that is fine. If you expected round-tripping through the viewer, the README gives no indication that it is supported.

The breadth of the import list is not self-contained either. The README names the external libraries the project depends on: three.js, pickr, fflate, draco, rhino3dm, web-ifc and occt-import-js. Several of the CAD and BIM formats are handled through those dependencies rather than by code written specifically for the viewer. That is a normal arrangement for a project of this scope, but it means the fidelity of a given format depends on the library underneath it, and the README does not make per-format accuracy claims.

How the engine is packaged: source/engine, esbuild and the module build

The repository separates the engine from the website. The package.json declares "type": "module" and points main at ./build/engine/o3dv.module.js, so consumers import a prebuilt ES module rather than the raw sources. The files field lists what actually ships: build/engine/o3dv.min.js, build/engine/o3dv.module.js, build/engine/o3dv.module.d.ts, source/engine/* and website/assets/envmaps/*. A TypeScript declaration file is included, which is a concrete signal that the maintainers expect programmatic use.

The build pipeline is visible in the scripts. build_engine runs update_engine_exports and then esbuild on source/engine/main.js with --bundle --minify --global-name=OV, writing build/engine/o3dv.min.js. build_engine_module produces the module variant. The global name OV is what a script-tag consumer would see on the window object.

For anyone working on the project itself, the scripts also include lint (eslint over source), test (mocha), generate_docs and create_package, which chains generate_docs, build_engine, build_engine_module, build_website and a Python packaging step. The presence of run-python3 in several scripts means a Python 3 interpreter is part of the contributor toolchain alongside Node. The README does not document the required versions of either.

Installing the package and loading your first model

The npm package is the documented route for embedding the viewer. Install it by name:

npm install online-3d-viewer

The package ships an ES module, so import it from your own module code. The README does not print a minimal initialisation snippet, and the developer documentation at kovacsv.github.io/Online3DViewer is where the API reference lives. What the repository does establish is that the module entry point is build/engine/o3dv.module.js and that a TypeScript declaration file accompanies it, so an editor with TypeScript support will resolve the exported names.

If you would rather not build anything, the hosted site takes a model URL directly. The README's own example link uses a hash fragment with a model parameter:

https://3dviewer.net/#model=https://raw.githubusercontent.com/kovacsv/Online3DViewer/dev/test/testfiles/gltf/DamagedHelmet/glTF-Binary/DamagedHelmet.glb

Opening that URL loads the DamagedHelmet glTF-Binary sample from the repository's test files. The same pattern is the quickest way to check whether a given format renders acceptably before you commit to embedding the engine.

For local development of the project itself, the start script runs build_website_dev and then http-server:

npm start

The README does not state which port http-server uses by default, so check the output when it starts.

Where Online3DViewer is the wrong tool

The export list is the first hard boundary. Seven formats go out, eighteen come in. Anything you need to write back as STEP, IGES, FBX, IFC or a dozen others is out of scope, and the README offers no workaround.

The second boundary is the nature of the viewer. This is a browser tool. Large assemblies that a desktop CAD application would stream from disk have to be fetched and parsed in the page, and the README makes no claim about model size limits, memory behaviour or load times. There is no documented server-side rendering mode or headless batch conversion path, so using it as a conversion service is not something the repository documents.

The third is documentation depth. The README is short and mostly a format list plus links. It does not document rollback for the engine, does not state supported browser versions, and does not describe error behaviour when an import fails. The developer documentation is generated by a script (generate_docs) and hosted separately, so the README alone will not answer API questions. If you need a viewer with a written compatibility matrix, this is not it.

Alternatives and how their approach differs

three.js is the closest comparison, and the relationship is not adversarial: Online3DViewer lists three.js as a dependency. The difference is level. three.js is a rendering library. You get a scene graph, materials, cameras and loaders for a handful of formats, and you write the viewer around it: file input, camera controls, environment maps, the UI. Online3DViewer wraps that work and adds importers for CAD and BIM formats such as step, iges, brep, fcstd and ifc through occt-import-js, rhino3dm and web-ifc. Choosing three.js directly makes sense when you need control over rendering and only care about glTF or OBJ. Choosing Online3DViewer makes sense when the formats are the problem, not the rendering.

A second comparison is the desktop route: opening the file in the application that produced it. That gives full fidelity and full editing, at the cost of installing software and, frequently, a licence. Online3DViewer trades fidelity guarantees and editing for zero installation and a URL. Which trade is acceptable depends entirely on whether the model needs to be measured and edited or merely looked at.

Maintenance, releases and licence

The repository is not archived, and the last push was on 2026-06-24. That is roughly three months before the date of writing, so the project is being touched, though the push date alone says nothing about the size or nature of the changes. The release history shows 0.18.0 on 2025-12-18, 0.17.0 on 2025-12-06 and 0.16.0 on 2025-05-24, and package.json declares version 0.19.0. The gap between 0.16.0 in May 2025 and 0.17.0 in December 2025 is seven months, so release cadence has not been uniform. The version in package.json being ahead of the newest published release suggests work in progress on the default branch.

Upgrade cost is hard to estimate from the README, because it does not describe a changelog or a deprecation policy. The build scripts and the generated documentation mean a contributor needs Node plus Python 3 and the esbuild toolchain; a consumer of the npm package needs neither. The MIT licence is permissive and the repository carries LICENSE.md at the top level, but the bundled dependencies (three.js, rhino3dm, web-ifc, draco and others) carry their own licences, and the README does not summarise them. Check those separately before shipping; this is not legal advice.

Editorial conclusion

Adopt Online3DViewer when you need a browser-based viewer for CAD and mesh formats without running a desktop application, or when you want the engine embedded in your own page through the online-3d-viewer npm package. Do not adopt it if your pipeline depends on a format outside the documented import list, or if you need a documented rollback path for engine upgrades, because the README does not describe one. Before committing, verify that the formats you actually receive are in the import list, and confirm the export formats match what your downstream tools accept.

Frequently asked questions

Official sources

1. kovacsv/Online3DViewer on GitHub
2. License: MIT
3. Project website
4. README
5. Releases