xeokit-sdk is a WebGL toolkit for putting IFC and point cloud models in the browser

A viewer SDK, not a viewer

The distinction that decides whether you want this project is in the README's usage section: the SDK lets us develop our own browser-based BIM viewer, which we can fully customize and extend with plugins. You are not embedding a finished product. You are taking a rendering and loading toolkit and building the application around it.

What the toolkit gives you is a Viewer with a camera and a scene, plus a set of loader plugins that each understand one format. The README's example creates a `Viewer` bound to a canvas, then a `XKTLoaderPlugin` that loads an XKT model into it. The model in that example was pre-converted from an IFC model taken from the Open IFC Model Database.

The topics attached to the repository describe the intended range: IFC viewing, point clouds, LAS and LAZ, 3D Tiles, geospatial data and BIM, all under a web viewer umbrella. The package description says the toolkit is based on pure WebGL for performance, with real-world coordinates and full double precision, which is the positioning that matters for engineering work: a BIM model in metres, with coordinates that do not lose precision when the model is large.

So the question to ask is not whether xeokit renders a model. It certainly does. The question is whether you want to build the viewer, its navigation, its model tree, its selection and measurement tools yourself, on top of a rendering core that already handles the hard parts of geometry.

Five loader plugins, and one recommended conversion path

The loader set is the concrete part of the API surface, and the README names each plugin explicitly.

`XKTLoaderPlugin` loads the XKT format, and the README presents the XKT route as the one used in its own example. `GLTFLoaderPlugin` handles glTF, which is the general 3D interchange format. `CityJSONLoaderPlugin` loads CityJSON, the encoding for city-scale 3D data. `LASLoaderPlugin` is listed for LAZ, and the plugin name and its linked documentation point at the LAS and LAZ point cloud side of the toolkit. `OBJLoaderPlugin` covers OBJ.

The README's framing is instructive. It says this is just one way to load models, and that IFC is handled by pre-converting to XKT and loading with the XKT loader, rather than by parsing IFC in the browser.

That choice has consequences for your architecture. An IFC file carries a lot of semantic structure, and a viewer that wants a model tree, element metadata and classification needs that structure preserved through the conversion step, not thrown away and re-derived. The `saoEnabled` option in the example is the visible hint of that, since scene authoring objects are how the structure is carried across. But the conversion itself is a separate step, and the README does not describe that tool, so if you adopt this path you are adopting a pipeline, not just a library, and the converter is something you would need to evaluate separately.

If your source data is already glTF, CityJSON, LAZ or OBJ, you skip the conversion entirely and load the file directly.

The example is a single HTML file with a CDN import

The README's usage example is deliberately small. It is one HTML page with a canvas element and a module script that imports the SDK from a CDN and wires up a viewer, a camera and a loader.

<script id="source" type="module">

    import {XKTLoaderPlugin, Viewer} from
                    "https://cdn.jsdelivr.net/npm/@xeokit/xeokit-sdk/dist/xeokit-sdk.es.min.js";
    
    const viewer = new Viewer({
        canvasId: "xeokit_canvas",
        transparent: true,
        dtxEnabled: true
    });
</script>

The viewer takes a `canvasId`, and the loader is constructed with the viewer and then handed a load configuration: an `id`, a `src`, and flags for scene authoring objects, edges, and the dtx texture compression option. The camera is positioned by assigning `eye`, `look` and `up` as three-element arrays, which is the standard three.js style convention and is worth noting because it means the camera model comes from that lineage.

The load options are the interesting part for an engineering viewer. `edges: true` turns on edge rendering, which is what makes a BIM model legible rather than a set of shaded boxes, `saoEnabled: true` switches on screen space ambient occlusion for depth cues, and `dtxEnabled: true` enables compressed textures, which matters when a model ships with large texture sets. `transparent: true` on the viewer is there for compositing the canvas over your own page rather than using an opaque background.

The same example is available to run online as a buildings example, so you can see the result without assembling the page yourself.

The npm install is one line, but the package ships ES modules only

Installation is a single npm command.

npm i @xeokit/xeokit-sdk

The deprecation notice in the README is the part to read carefully, because it changes what your build must accept. Starting from September 2026, the ES5 and UMD and CommonJS builds will no longer be included in the npm package. The stated reason is that maintaining ES5 compatibility requires extensive transpilation and polyfilling that is increasingly difficult to sustain as the codebase evolves. Going forward only the ES module builds, `xeokit-sdk.es.js` and `xeokit-sdk.min.es.js`, will be provided, described as compatible with all modern browsers and bundlers.

Practically, that rules out two things. A project that loads the SDK from a script tag with a global variable, and a build pipeline that consumes CommonJS, will both need to change. The package.json still lists a `main` entry pointing at `./dist/xeokit-sdk.cjs.js` and a `module` entry pointing at `./dist/xeokit-sdk.es.js`, and the type definitions sit in `./types/index.d.ts`.

It also means the migration is not optional for new projects, and for existing ones it is dated rather than immediate. The esbuild, webpack and Vite users are fine. A legacy app server rendering a global script tag is not.

AGPL-3.0 is the decision that has to come first

The licensing section is the sharpest constraint in the README. xeokit SDK is licensed under AGPLv3, which the README states requires that any modifications or integrations of xeokit SDK into a project must also be open-sourced under AGPLv3.

That is a strong requirement, and it lands hardest on the case the SDK is most attractive for: an engineering firm with a proprietary product and a paying customer base. If your viewer is a differentiator you do not want to publish, AGPL-3.0 is a genuine problem rather than a checkbox.

The README addresses this directly. If your company requires the SDK under a different licensing model for proprietary or closed-source applications, the project offers flexible commercial licensing options, with contact at [email protected] and a pricing page on xeokit.io. The SDK is by Creoox AG, so the commercial path is with the vendor rather than a community process.

This is a reading of the licence identifier and the README's own summary, not legal advice, and the AGPL text governs. The practical takeaway is procedural rather than technical: settle the licence question before you build on the toolkit, because the answer determines whether you can ship what you build, and discovering the answer after six months of integration is expensive.

The rest of the repository is set up like a well-run commercial open source project. There is a CHANGELOG.md, a SECURITY.md, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md and a typedoc configuration with generated typedocs, and a playwright configuration for end to end tests.

Rolling betas on a 2.6.x line, pushed daily

The release pattern is worth understanding before you pin a version. The listed releases are v2.6.114 on 2026-09-02, followed on the same day by v2.6.115-beta and then v2.6.115-beta2. The last push to the repository was on 2026-10-19, so work continues on the default branch between releases.

The pattern suggests a stable patch release followed immediately by betas for the next one, which is a common pattern for a project that wants a usable release available while the next one settles. For a consumer, the practical effect is that a beta tag is not a safe thing to pin a production build to, and that the stable patch tag moves.

The version in the package.json is 2.6.114, matching the latest listed stable release, which tells you the published package is not on the beta line. The build is done with rollup across three configurations, `rollup.config.js`, `rollup.minified.config.js` and `rollup.dev.config.js`, and the scripts print a warning that the `npm run {build,dev-build,test}` scripts and the devDependencies are soon going to be deprecated, with the advice to install a build tool and execute it directly. Tests run through Playwright under Percy for visual comparison.

Two of the top-level entries are unusual for a viewer library and are worth knowing about. `test-scenes/` holds scene files, and `CLA-Creoox.pdf` is a contributor licence agreement sitting in the repository root.

Editorial conclusion

xeokit-sdk fits a company building a proprietary AEC product that needs a real model viewer, has the engineering judgement to own a WebGL pipeline, and can live with AGPL-3.0 obligations or a commercial licence. It does not fit a team that wants a hosted viewer, that only needs to show one model occasionally, or that intends to ship the viewer in closed source without buying a licence. Before you start, read the AGPL-3.0 terms in the LICENSE file, note that the ES5 and CommonJS builds stop shipping from September 2026 so your build must consume the ES module build, and check the CHANGELOG.md for breaking changes given the release line is still shipping 2.6.x betas.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. xeokit/xeokit-sdk on GitHub