Convert OBJ to STL

This conversion is almost always compliance rather than preference. An online print service lists `.stl` in its accepted formats. A CAM package imports meshes and imports exactly one kind. A machine vendor’s software was written around STL and has not been revisited. A workshop asked for "an STL" because that is the word for a printable file in their vocabulary.

Arguing is rarely available and usually not worth it. What is worth doing is making sure the STL you hand over is the one you meant, because an STL states nothing about itself — no units, no part names, no material, no provenance — so every mistake in it is silent until something is machined at the wrong size. The rest of this page is the checklist.

An OBJ frequently arrives with a companion: an `.mtl` file naming materials, and a folder of texture images the `.mtl` points at. The `mtllib` and `usemtl` lines in the OBJ reference them. None of that is read, because there is nowhere in an STL to put a material, a texture, a UV coordinate or a colour.

The consequence is worth being blunt about. A model bought from a marketplace because it looked good arrives as a plain grey solid, and that is not a shortcoming of the conversion but the definition of the target format. A handful of tools have written colour into the two spare bytes of each STL triangle record over the years, in two incompatible conventions; neither is part of the format and neither is produced here. If colour matters, 3MF is the printing format that carries it.

OBJ organises geometry with `o` and `g` lines, and a model of any complexity uses them — a body, a lid, a handle, each named. An STL has one list of triangles from beginning to end and no notion of an object, so all the groups are written into it in the order they appeared.

The shells stay geometrically separate and the identity is gone. PrusaSlicer and Cura both detect disconnected shells on load and offer to split them into separate objects on the plate, which recovers the arrangement but not the names — the parts come back as "Part 1" and "Part 2". If the receiving end needs to know which piece is which, say so in the message, or supply one STL per part by deleting the others in a modelling application first.

OBJ faces may have any number of corners, and STL triangles have exactly three, so every polygon is split. The method is a fan: corner one is joined to each consecutive pair, so a quad becomes two triangles and a hexagon becomes four.

That is exactly right for a convex face and it is the one place this conversion can produce geometry that is wrong rather than merely reduced. A concave polygon fanned from a corner outside its own interior produces overlapping triangles, which appear in the slicer as a folded or self-intersecting patch. Modelling packages almost always emit convex faces, so this is rare — but if the sliced preview shows a strange fold on a flat region, triangulate the OBJ properly first. Blender’s Triangulate Faces uses an ear-clipping method that handles concave polygons correctly.

Neither format records a unit. OBJ has no field for one, and the ecosystem around it has no convention either — a mesh from a scanning tool is often millimetres, one from an architectural package metres, one from a game asset pipeline whatever the engine used. STL is the same, except that every slicer ever written interprets it as millimetres.

So the numbers pass through and acquire a meaning they did not have. That is the single most expensive way this conversion goes wrong, and the check takes ten seconds: load the STL in a slicer, read the bounding box, and compare it with a dimension you know. A part that should be 60 mm across and reads 0.06 mm was authored in metres; one that reads 1524 mm was authored in inches. Scale before sending rather than asking the bureau to.

OBJ face indices are one-based, and the format also allows negative ones, which count backwards from the most recent vertex — a corner written as `-1` means the vertex declared immediately before this face. Some exporters use that form throughout because it makes concatenating files trivial.

Both forms are resolved as the file is read, in order, which is the only way it can be done: a negative index depends on how many vertices had been declared at that point, so it cannot be reinterpreted later. Corner specifications of the forms `v`, `v/vt`, `v//vn` and `v/vt/vn` are all accepted and only the vertex part is used, since the texture and normal references have no destination in an STL.

The reader merges coincident vertices within each group, comparing at six decimal places. That matters for the other targets on this site — an OBJ converted to glTF or PLY keeps the shared vertices and is much smaller for it — and it is invisible in an STL.

STL has no vertex sharing at all: each triangle carries its three corners independently, so a corner used by six triangles is written six times whatever the reader did. The file is therefore exactly 84 + 50n bytes for n triangles regardless of how tidy the source was — twelve bytes of face normal, thirty-six of coordinates and two unused, per triangle. The normal is recomputed from the winding order rather than carried across, since slicers derive it from the winding anyway and several ignore the stored value entirely.

Four things, in this order, and all of them in a slicer you control rather than in the bureau’s previewer. The bounding box, against a dimension you can verify. The object count, in case the model was several parts and you meant to send one. The manifold report — PrusaSlicer and Cura both flag open edges on load and offer a repair. And the sliced preview at a couple of heights, which shows whether the walls are where you think they are.

That last one catches things the others miss: inverted faces producing a hollow where there should be solid, a fanning artefact from a concave polygon, an internal shell nobody knew was there. A bureau will run its own repair before printing, and its repair is made without knowing which features of your part are functional.

If you are printing this yourself, 3MF is the better destination and every current slicer takes it: it declares millimetres explicitly, keeps each group as its own object on the plate, and is a compressed package rather than fifty bytes a triangle. The only reason to produce an STL for your own printer is a slicer old enough not to read 3MF.

If the model is going to be edited rather than made, keep the OBJ — it has the groups, the material references and a text form you can inspect, and none of that survives a trip through STL. And if the model was purchased, check what the licence permits before printing: marketplace terms routinely cover rendering and are silent about physical reproduction, which is a different right.

In this browser tab, by plain JavaScript. No WebAssembly module is fetched, nothing is uploaded, there is no account and no daily allowance, and the network tab during a conversion is the way to confirm it rather than this sentence.

The free ceiling is 100 MB on the input, and note that the output can be larger than the input for a dense model — an OBJ stores each vertex once and an STL repeats it per triangle. A model of a few hundred thousand triangles is comfortable; beyond a couple of million, most slicers become unhappy before this page does.