Chili3D: browser CAD built on OpenCascade compiled to WebAssembly

What Chili3D solves, and who is meant to use it

Installing a desktop CAD package is a procurement decision. The download is large, the licence usually costs money, and the file lives on one machine. Chili3D takes the other route: the README describes it as a browser-based 3D CAD application for online model design and editing, and the geometry work happens in the tab. The project compiles OpenCascade (OCCT) to WebAssembly and pairs it with Three.js, so the modelling operations are the same kernel calls a desktop application would make rather than an approximation written in JavaScript. The README states this is how it reaches near-native performance. That claim is the project's own wording, and the repository does not publish a benchmark against a native build, so treat it as a design goal rather than a measured result.

The audience is narrow and identifiable. Engineers who need to open a STEP file, take a measurement, or make a small edit on a machine where they cannot install software. People building internal tools who want a CAD surface they can embed and script. Developers who want to study how OCCT behaves behind an Emscripten boundary and a TypeScript interface layer. Anyone whose primary need is a full parametric feature tree with years of accumulated work in it is not the target, and the feature list reflects that: the README enumerates basic shapes, sketching, booleans, sweeps, lofts, fillets, chamfers, arrays, measurements, and import and export of STEP, IGES, BREP and STL. It does not describe a constraint solver or a history-based parametric model.

How the OCCT WebAssembly kernel reaches the viewport

The architecture section of the README lays out an npm workspace monorepo under packages/ with an interface-driven, pluggable backend. The dependency arrows matter more than the package list. Everything converges on core, which holds the abstract interfaces (IShape, IShapeFactory), the math types (XYZ, Matrix4, Plane), the document model, reactive primitives (Observable, Binding, PubSub), a Result<T,E> type, transactions with undo and redo, commands, serialization, the plugin system, and a service container.

The wasm package is the concrete ShapeFactory that calls into OCCT through Emscripten bindings. That is the seam: core defines what a shape factory must do, and wasm is one implementation of it. The three package owns the viewport, camera controller, visual objects, highlighter, outline pass, gizmo and mesh export. The ui package holds the ribbon, property panels, project tree and dialogs. The app package contains the concrete Application, the body node classes, command implementations, CommandService and HotkeyService. The builder package exposes an AppBuilder with a fluent chain, which the README gives as .useIndexedDB().useWasmOcc().useThree().useUI().build(). The web package is the entry point that calls AppBuilder, shows a loading screen and parses URL parameters.

That chain is the clearest statement of the data flow. A document is persisted through IndexedDB, geometry operations are delegated to the WASM factory, the result is turned into visual objects for Three.js, and the UI drives it all through commands. The interface-driven split means a different kernel could in principle sit behind IShapeFactory, though the repository ships only the OCCT implementation.

Running Chili3D locally: clone, install, npm run dev

The README lists Node.js and npm as the only prerequisites. Clone the repository and install the workspace dependencies first.

git clone https://github.com/xiangechen/chili3d.git
cd chili3d
npm install

Then start the development server. The README gives the port explicitly.

npm run dev   # Launches at http://localhost:8080

Open http://localhost:8080 and you should see a loading screen while the WASM module initialises, then the ribbon interface. The prebuilt WASM module is included in the repository, so this path does not require the Emscripten toolchain. If you want to build the kernel from source instead, the README describes a one-time setup step followed by the build.

npm run setup:wasm
npm run build:wasm

For a container deployment, the repository ships a Dockerfile and a compose.yml. The compose file maps port 8080 on the host to port 80 in the container, and the Dockerfile builds with npm install && npm run build before copying the dist directory into an nginx:alpine image.

docker compose up -d   # Builds and serves the app at http://localhost:8080

A first real use is to create a basic shape and export it. The README lists boxes, cylinders, cones, spheres, pyramids and torus among the basic shapes, and STEP, IGES, BREP and STL among the export formats. Create a box, apply a fillet from the modification tools, then export to STEP and re-import it to confirm the round trip. Testing and linting run through Rstest and Biome with npm run test and npm run check.

Where the browser kernel approach costs you

The first limitation is the one the README does not discuss: the WASM module has to be fetched and initialised before anything works. The web package shows a loading screen for exactly this reason. On a fast connection that is a delay; on a slow one it is a barrier, and the repository does not document a size figure for the module or a strategy for caching it beyond what the bundler does. If your users are on constrained networks, measure the load before you plan around it.

The second is document persistence. Storage is IndexedDB through the storage package. That is per-browser and per-origin. The README documents create, open and save documents, and import and export of STEP, IGES, BREP and STL, but it does not describe multi-user collaboration, a server-side document store, or conflict resolution. If two people need to work on the same assembly at the same time, this is the wrong tool, and nothing in the repository suggests otherwise.

The third is the absence of a parametric history model. The editing tools are direct: chamfer, fillet, trim, break, split, sew, simplify, move, rotate, mirror, arrays, feature removal, sub-shape manipulation, explode. Those are operations applied to shapes, not features recorded in a tree that can be replayed after a dimension change. A user coming from a history-based CAD package will find that changing a box from 40mm to 50mm after three downstream operations is not the same interaction. The README does not claim it is.

The fourth is maintenance signal. The last push to the default branch was on 2026-09-19, and release 0.7.1 is dated the same day, with 0.7.0 on 2026-08-23 and 0.6.1 on 2026-01-26. That gap between January and August is worth noting if you are planning to depend on the project. The repository is not archived, and the release cadence resumed, but a seven-month stretch between minor releases is the kind of thing to check against your own timeline.

Chili3D against FreeCAD and the browser-first tools

The closest desktop comparison is FreeCAD, which also builds on OpenCascade. The difference is where the kernel runs and what that buys you. FreeCAD runs OCCT natively, so it has no WebAssembly boundary, no browser memory ceiling, and access to the full local filesystem, Python scripting and a large body of community workbenches. Chili3D pays for portability with the constraints of the browser sandbox: the same kernel, but behind an Emscripten binding layer and a TypeScript interface, with documents in IndexedDB rather than on disk. If you need Python automation or a mature workbench ecosystem, FreeCAD is the answer and Chili3D is not.

The browser-first comparison is the shape-modelling tools people reach for when they want something quick. Those are built for direct manipulation of simple solids and generally do not expose a B-rep kernel, STEP import and export, or operations like sweeping, lofting, offset surfaces and shape repair. Chili3D's README lists all of those. That is the real distinction: it is not a simpler tool, it is the same class of kernel as a desktop package, delivered through a different runtime. The trade is that you inherit the loading cost and the storage model in exchange for not installing anything.

A third option worth naming is Onshape, which also puts CAD in the browser but does so with a server-side kernel and a commercial subscription. Chili3D keeps the kernel on the client and is AGPL-3.0 licensed. The architectures are not comparable in operational terms: one is a hosted service, the other is a bundle you serve yourself.

Licence and the cost of staying current

Chili3D is licensed AGPL-3.0. The practical consequence is the network clause: if you modify the software and let users interact with it over a network, the AGPL's terms reach that deployment in a way the GPL's do not. Running an unmodified build for internal use is a different situation from shipping a modified build as part of a product. This is not legal advice, and the specific obligations depend on what you change and how you distribute it; read the LICENSE file and get proper advice before building on it commercially.

The upgrade cost is dominated by the WASM boundary. The README pins OpenCascade 8.0.0 and Three.js 0.184 in the technology stack. When either moves, the Emscripten bindings in cpp/ and the shape factory in packages/wasm are where the work lands, and that is C++ and binding code rather than TypeScript. The repository includes AGENTS.md and CLAUDE.md at the top level, which suggests the maintainers expect agent-assisted contributions, but neither changes the fact that kernel upgrades are the expensive kind.

Day to day, the toolchain is conventional: npm workspaces, Rspack 2 for bundling, Biome for TypeScript with a 4-space indent and 110-character line width, clang-format with WebKit style for C++, Rstest with Happy-DOM for tests, and pre-commit hooks through simple-git-hooks and lint-staged. A contributor runs npm run check before a pull request. The optional WASM build needs the Emscripten dependencies installed through npm run setup:wasm, which is a one-time cost per machine.

Editorial conclusion

Adopt Chili3D if you want a CAD kernel in the browser, need STEP or IGES import and export, or want to extend the command set through the plugin API. Do not adopt it if you need a mature parametric history tree, a large third-party plugin ecosystem, or vendor support, because the repository documents none of those. Before committing, verify that the prebuilt WASM module loads on your target browsers, that your STEP files survive a round trip through the reader and writer, and that AGPL-3.0 fits how you plan to distribute anything you build on top of it.

Frequently asked questions

Official sources

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