GLB to STL

Your model never leaves your browser, and nothing is downloaded to make this work. A mesh is a list of points and a list of triangles; reading one and writing the other is arithmetic your browser can already do.

…or drop one anywhere on this page.

Into the format every slicer opens, and the one with the most to say about what it loses: no materials, no colour, no names, and no way to share a corner between triangles, so the file grows.

A GLB is a glTF with its numbers packed into the same file, which is why it is the one to ask for when a program offers both. It is a whole scene rather than a single mesh, so the parts are put where the file says they go rather than where their own coordinates would have left them.

None of these formats has units

This is the single most common reason a model comes out wrong, and no converter can fix it, because there is nothing in the file to read. Both of these formats are lists of numbers. Whether 10 means ten millimetres, ten inches or ten of something else is a convention between whoever exported the file and whatever opens it next — it is not written down. That is why models arrive at twenty-five times their intended size, or a twenty-fifth.

So the dimensions are shown above as three bare numbers. If your object is meant to be about 60 long and it says 2.36, somebody wrote it in inches and something else is about to read it as millimetres. The numbers are yours to recognise; nothing here can do it for you. If you want the size recorded in the file, convert it to 3MF instead — that is the one format here that stores it.

A glTF is a scene, not a mesh

The numbers in the buffer are each part's own coordinates. Where that part actually sits is recorded separately, on the node pointing at it — as a matrix, or as a translation, a rotation and a scale. Nodes nest, so a wheel's position is its own transform times its axle's times the car's.

A reader that ignores all that produces a perfectly valid mesh, with exactly the right number of triangles and vertices, in which every part of the model is stacked at the origin, interpenetrating. Nothing about the file looks wrong. It is the single most common way a glTF conversion goes wrong, and it is why the reader here carries a matrix down the node tree and reports how many parts it moved.

An STL repeats every corner

An STL has no way to say that two triangles share a corner. There is no vertex list and no index; each triangle carries its own three points. So a corner where six triangles meet is written out six times, to full precision, every time.

A cube is eight corners, and an STL stores thirty-six. That is the whole reason the file gets bigger on this page, and it is the format doing it rather than the conversion: the box that trimesh writes is 433 bytes as an OBJ and 684 as a binary STL, and its 320-triangle sphere is 9,807 bytes against 16,084. On a scan of a few million triangles the difference is not small.

Nothing is lost by it — the shape is identical, and the corners weld back together coming the other way. It is just larger, and now you know why.

What does not come across

Everything except the triangles. An STL has no colour, no materials, no texture coordinates, no object or group names and no scene — it is geometry and nothing else, which is exactly why every slicer reads it. Faces with four or more corners are split into triangles. Face normals are recalculated from the three corners rather than copied, because a stored normal that disagrees with the geometry is worse than none and a great many files have them wrong.

Whether it is watertight is reported above, because that is what a slicer is about to ask: a closed solid has every edge shared by exactly two triangles, and one that does not leaves the slicer guessing what is inside. This is measured after welding — straight off an STL no two triangles share a corner by index, so every model on earth would look full of holes. Nothing here repairs a mesh; it tells you, and repairing is a different job.

Nothing is rotated. glTF is Y-up by its specification, COLLADA records an up axis of its own, and STL, OBJ and PLY say nothing at all — in practice arriving Z-up from CAD tools. What a file declares is reported rather than acted on, because a silent rotation is far worse than a model you can turn yourself. If your object arrives lying on its side, that is why, and it is one rotation in whatever opens it next.

Where to go next