OBJ → STL

Convert OBJ to STL for 3D printing

Free to start

Turn an idea into a game-ready 3D model.

Converters are for finishing and engine import. Need a new game asset? Generate one from a prompt or an image in Studio before choosing an export format.

Create a free account and 100 credits are added straight away — enough to generate your first model. The converter, polygon counter, LOD builder, pivot and viewer stay free and need no account.

OBJ is the format ZBrush, MeshLab, photogrammetry apps and most scan/CAD tools export by default. STL is what your slicer actually needs. This turns an OBJ straight into a print-ready STL.

obj to stl converter · convert .obj to .stl · wavefront to stl · obj to stl for printing

Why convert OBJ to STL?

OBJ has been the universal static-geometry format for 30 years — it's what comes out of a ZBrush sculpt, a MeshLab cleanup pass, a photogrammetry scan, or most CAD software's "export mesh" option. But a slicer doesn't read OBJ; it reads STL. Both formats describe geometry only, so the conversion is close to lossless on the parts that matter for printing: vertex positions and faces carry over exactly.

What's dropped is what a slicer would ignore anyway — UV coordinates, the sibling .mtl material file, vertex colors. None of that affects the print. One real difference: OBJ can store quads and n-gons, while STL is triangles-only, so any non-triangular faces get triangulated during export — invisible to the naked eye and irrelevant to slicing, but worth knowing if you're comparing face counts between the two files.

If your OBJ came from a scan or sculpt with a lot of raw, noisy topology, consider running the Reduce tool first — fewer, cleaner triangles slice faster and produce a smaller STL without any visible loss of detail at print resolution.

What survives the OBJ → STL conversion

Computed automatically from the capabilities of each format.

Feature OBJ STL Status
Geometry (vertices & faces) Preserved
UV texture coordinates Lost
Vertex normals Preserved
Basic materials (diffuse, specular) Lost
Multiple meshes in one file Lost

When you need this conversion

Printing a ZBrush sculpt or Blender model exported as OBJ
Preparing a photogrammetry or phone-scan (Polycam, RealityCapture) OBJ for printing
Turning a MeshLab-cleaned scan into a slicer-ready STL
Converting a CAD tool's mesh export to STL for a resin or FDM printer

Tips

High-poly scans and sculpts: run the Reduce tool first. Fewer triangles means a smaller, faster-slicing STL with no visible quality loss at typical print resolutions.
Binary STL output here is 2-4× smaller than ASCII — every modern slicer reads it without any settings change.
If your OBJ has multiple named groups/objects, they merge into a single STL mesh — STL has no concept of separate parts within one file.

Common pitfalls

Read these before converting — they save hours of debugging in your engine.

OBJ has no enforced unit either — check before you print

Neither OBJ nor STL embeds a unit. If your OBJ came from a scanning or CAD tool already working in millimeters, the numbers carry straight through with no surprises. If it came from a DCC tool that treats 1 unit as 1 meter (common in Blender exports authored at real-world scale), expect the same ~1000× mismatch you'd get from any meter-scale source — check your model's dimensions in the slicer before printing.

Quads and n-gons get triangulated

STL only stores triangles. Any quad or n-gon face in the source OBJ is split into triangles on export — this is required for STL and has no visual or print-quality effect, but face counts between the two files won't match 1:1.

Watertightness still matters

Scans and sculpts are common sources of non-manifold geometry (open edges, self-intersections, floating internal shells). A slicer needs a closed volume to compute infill and walls — if it flags the STL as broken, repair it in your slicer's built-in tool or Meshmixer before printing.

UVs, .mtl and vertex colors are dropped

STL has no material system, so the OBJ's texture coordinates and referenced .mtl file are not carried over. This never affects printing — a slicer ignores color and texture data regardless of source format.

Frequently asked questions

Does converting OBJ to STL lose any print-relevant detail?
No. Vertex positions and faces — the only things a slicer reads — carry over exactly. What's dropped (UVs, materials, vertex colors) has no effect on printing.
My OBJ has quads — will the STL still be accurate?
Yes. STL requires triangles, so quads and n-gons are triangulated automatically during export. The resulting surface is geometrically identical; only the internal face count differs.
Why does my slicer say the STL is too big or too small?
Neither OBJ nor STL stores a unit, so scale depends entirely on what convention your source tool used. Check the model's dimensions in your slicer and rescale (commonly ×1000 or ÷1000) if the source was authored in meters rather than millimeters.
Will this fix a non-manifold scan for me?
No — topology passes through unchanged. If your slicer reports the mesh as not watertight, run its built-in repair or a tool like Meshmixer before printing.

Related conversions

Need to do this from your backend? See the API.