Convert STL to GLB: the scale gotcha nobody warns you about
You exported a 40 mm bracket, converted the STL to a GLB, dropped it into three.js or <model-viewer>… and it's either filling the whole scene like a building or nowhere to be found. The geometry is fine. The conversion "worked." So what happened? I build Cadre, a browser CAD tool, and we just shipped an STL→GLB converter — so I spent a while staring at exactly this bug. It's worth explaining, because almost every STL→GLB tool gets it wrong and never tells you.
The short version
STL has no units. glTF is defined in meters.
An STL file is just numbers — a list of triangle coordinates with no statement of what those numbers mean. By near-universal convention they're millimeters, but the file never says so. glTF (and its binary form, GLB) is the opposite: the spec says one unit equals one meter, full stop.
So the obvious conversion — read the STL's numbers, write them into the GLB unchanged — quietly reinterprets 40 from "40 millimeters" to "40 meters." Your bracket is now 1000× too big. In a viewer that auto-frames the camera, you might not even notice; it just fills the frame. But the moment scale matters — augmented reality, a physics simulation, compositing next to a correctly-sized model — it's badly wrong.
Why so many converters do this
Because copying the numbers across is the path of least resistance, and it looks like it works. The mesh is right. It loads. It renders. The bug only shows up downstream, in someone else's tool, under conditions the converter author never tested. If the converter runs server-side and hands you a file, there's no feedback loop telling anyone the scale is off.
The fix is trivial once you know to do it: multiply every coordinate by 0.001 on the way out (millimeters → meters). A 40 mm bracket becomes 0.04 in the GLB, and now it's 40 mm everywhere that 40 mm means something. Cadre's converter does this as it writes the file. It's a one-line idea that an astonishing number of tools skip.
The other half: which way is up
There's a smaller sibling to the scale bug: axis convention. Some CAD tools are Z-up; glTF is Y-up. Convert from a Z-up source without rotating and your model lies on its side in every web viewer. (Cadre's kernel is already Y-up — the same as glTF — so this one's free for us, but it's worth checking if your model comes out of a Z-up tool.)
What you don't get from an STL→GLB conversion
Honesty, because the gap between expectation and reality is where the frustration lives: converting an STL to GLB does not give you color, materials, or textures. An STL never carried any of that, so there's nothing to recover — the body comes through with a plain neutral material. GLB's real strength is rich PBR materials, but that has to come from a model that has materials. If you want a colored or textured GLB, you need to build it that way: in Cadre you can model or import bodies, give each one a color, and export a GLB where each body keeps its color as a real glTF material.
What conversion is great for: getting existing mesh geometry onto the web. Embedding a part on a page with <model-viewer>, loading it into a three.js scene, sending someone a file that opens in Blender or Windows 3D Viewer, or feeding the AR pipeline (GLB is the source format Android Scene Viewer reads and that converts cleanly to USDZ for iOS).
Doing it without uploading your file
Most "free online STL to GLB" tools upload your file to a server. If your geometry is a product you haven't shipped yet, that should give you pause. Cadre's STL→GLB converter runs the actual geometry kernel — the same Rust code that powers the editor, compiled to WebAssembly — inside your browser tab. Drop a file, get a spec-conformant glTF 2.0 binary back, scaled to meters and Y-up, with nothing sent anywhere and nothing retained.
If you want to go further than a straight conversion — clean up the mesh, combine parts, add per-body color — open the editor and export GLB from there. Same kernel, same no-upload promise, plus everything an STL can't carry.