Convert STL to glTF

No browser renders an STL and no browser renders a glTF either — both need a runtime. What differs is the quality of the path. three.js ships an STL loader, so the naive answer is to serve the STL directly and be done, and for a one-off internal tool that is a reasonable answer.

It stops being reasonable when the page is public and the model is the content. An STL is the least efficient way to move a mesh over a connection that exists, it carries no bounds so the camera has to be computed after parsing, and every triangle arrives with its own three vertices for the GPU to deduplicate or not. glTF was designed for this exact transfer and fixes all three.

A binary STL is exactly 84 + 50n bytes for n triangles, regardless of the shape. Fifty of those bytes are twelve for a face normal, thirty-six for three full vertices, and two unused. Nothing is shared: a cube is thirty-six vertex records for eight distinct corners.

The conversion rounds coordinates to six decimal places to build a key and collapses every corner at the same position into one vertex. On a closed surface each vertex typically serves five or six triangles, so the vertex data falls by roughly that factor before it is written as float32. Add twelve bytes of uint32 indices per triangle and the glTF geometry lands well under the STL for any mesh that is actually closed.

One scene, one node, one mesh, one primitive in triangle mode, a float32 VEC3 position accessor and a uint32 SCALAR index accessor. The asset block declares version 2.0. The buffer is embedded as a base64 data URI, so the file is self-contained.

The POSITION accessor carries min and max, which the specification requires and which is the practical difference between a model that appears and one that does not. model-viewer and three.js both derive their initial camera distance from those six numbers; a file written without them opens zoomed to nothing, and that failure is indistinguishable from a broken load until you inspect the JSON.

No NORMAL attribute is written, and the glTF specification instructs viewers to compute flat face normals when a mesh has none. On an organic model imported from a sculpting tool that is a defect and people ask how to fix it. On a part that came out of CAD as an STL it is the truth.

An STL has no curved surfaces. It has the triangles the exporter produced at whatever chord tolerance was set, and a smooth-shaded render of them is a flattering lie about the geometry a printer will actually reproduce. If you want the preview to look smoother, the honest fix is upstream — re-export the STL with a finer tolerance so there are more triangles — rather than averaging normals to hide the ones you have.

STL declares no unit and the engineering and printing worlds read its numbers as millimetres. glTF 2.0 defines its linear unit as the metre. The conversion copies the coordinates through unchanged, because rescaling by a factor the source never stated would be a guess.

So a 60 mm bracket becomes a 60-metre bracket in glTF terms. Nothing looks wrong in isolation — the camera frames it from the bounds and the model fills the view — but it will be wrong the moment it sits next to anything else in a scene, and physically-based lighting behaves differently at that scale. Set a uniform 0.001 scale on the node in your viewer, or apply it in gltf-transform once at build time.

Because an STL has no parts, groups or objects, the glTF contains exactly one primitive. That is the cheapest possible thing to render and it means an STL-derived model never suffers the draw-call problem that a CAD export with three hundred groups creates.

It also has no material, no texture, no UV coordinates and no vertex colours, because an STL held none of them. Your viewer applies its default, which is usually a mid-grey physically-based material. Assigning something better in three.js is one line, and it is worth doing: a technical part reads far more clearly with a slightly metallic material and an environment map than with the default.

The .gltf written here embeds its buffer as a base64 data URI, so there is no .bin to serve alongside it and no relative path to break. Base64 costs four characters per three bytes, so that convenience is about 33 percent more bytes, on top of pretty-printed JSON.

For a file you are going to inspect, diff, or feed to gltf-transform at build time, take the glTF. For the file the visitor actually downloads, take the GLB: same geometry, same bounds, binary buffer, one request. Converting an STL to either is the same operation here, and the extension is the whole difference.

Binary and ASCII STL share an extension and the file does not say which it is. The common test — checking whether the file starts with the word "solid" — is unreliable, because the eighty-byte header of a binary STL can contain any text and several writers put "solid" there.

The reliable test is arithmetic: a binary STL is exactly 84 + 50n bytes for the triangle count in its header, and nothing else is. That is what this converter uses. If the length does not match, the file is decoded as text and its vertex lines are read. Either way the model reaches the same welded form before the glTF is written.

Nowhere. The pair runs as plain JavaScript in the page — no WebAssembly engine to download, no request carrying the model, no queue. That matters more than usual for this pair, because the STLs people convert for a web preview are frequently a customer's part or an unreleased product, and a print bureau that quotes on uploaded geometry has a real reason to care where it went.

The free ceiling is 100 MB, which at fifty bytes a triangle is a two-million-triangle model. Files that large are worth decimating before conversion rather than after: the glTF will be proportionally huge, and a browser viewer on a phone will not enjoy it whatever format it arrives in.