3D file formats explained: STL, OBJ, 3MF, STEP and the rest

If you’ve ever exported a model and wondered why your slicer is complaining, or why your circle looks like an octagon, the answer is usually the file format. There are about a dozen formats floating around in the 3D printing world, and they all make different tradeoffs.

Here’s what each one actually does, where it breaks down, and how to pick the right one.

STL: the old workhorse

STL (Stereolithography) has been around since 1987. Chuck Hull’s team at 3D Systems created it for the SLA-1, the first commercial 3D printer. The format needed to get CAD geometry into a laser control system, and triangles were the simplest way to approximate any surface.

That’s all STL stores: triangles. Each one is defined by three vertices and a normal vector. No color, no units, no material info, no metadata. The number “10” in an STL file could mean 10mm, 10 inches, or 10 meters - the format doesn’t say.

This “data poverty” causes real problems:

Curved surfaces are faked. A cylinder becomes a polygon with 32 or 64 sides. Zoom in and you see flat facets. To get smoother curves, you need more triangles, which means bigger files. There’s a direct analogy to raster images here - STL is to 3D what JPEG is to 2D. The mathematical intent is gone; only the approximation remains. (We wrote more about how OpenSCAD handles this with its $fn parameter.)
No validation. STL files often have holes, overlapping triangles, or flipped normals. You end up running repair tools before you can print.
File bloat. If you have 100 identical bolts on a build plate, STL stores every triangle for every bolt separately.

So why is STL still everywhere? Inertia. Every slicer, every CAD tool, every 3D printing service accepts it. For single-material FDM prints, it works fine. The printer slices the mesh into layers and doesn’t care that your circle is really a 64-sided polygon.

OBJ: color and texture, but fragile

The Wavefront OBJ format came from the animation world in the early 1990s. Wavefront Technologies designed it for data exchange between rendering packages, not for manufacturing.

OBJ improves on STL in a few ways. It supports polygons with any number of sides (not just triangles), can describe NURBS curves, and handles texture coordinates (UV mapping). This makes it useful for multi-color and multi-material printing.

The catch is the multi-file dependency. Geometry lives in the .obj file, but materials and textures live in a separate .mtl file, which may reference external image files. If any of those links break, the color data is gone. This makes OBJ awkward for sharing - zip it wrong and you lose half the information.

OBJ also has no unit system. Like STL, the numbers are just numbers.

3MF: the modern replacement

The 3MF Consortium (Microsoft, HP, Autodesk, 3D Systems, and others) launched the 3D Manufacturing Format in 2015 to fix the problems with STL. It became an ISO standard (ISO/IEC 25422:2025) in 2025.

A 3MF file is a ZIP archive containing XML. This “container” approach lets it pack everything into one file:

Multiple objects with exact positions and orientations
Explicit units (millimeters, typically)
Integrated color and material data
Manufacturing metadata: authorship, slicer settings, support structures, infill patterns

3MF handles the 100-bolts problem too. It stores the geometry once and references it for the other 99 copies. And because the XML schema enforces manifold geometry, you can’t create the broken meshes that STL allows.

Modern slicers like PrusaSlicer, Bambu Studio, and OrcaSlicer now use 3MF as their project format. When you share a 3MF file, you’re sharing a ready-to-print job - printer profile, orientation, painted supports, everything.

For lattice structures and advanced manufacturing, the Beam Lattice extension is worth knowing about. It describes lattices as mathematical beams instead of meshes. A structure that takes 8MB in STL can be 11KB in 3MF beams.

Quick comparison

	STL	OBJ	3MF
Year	1987	~1990	2015
Units	No	No	Yes
Color/material	No	Separate .mtl file	Integrated
Multi-object	No	Yes	Yes
File size	Large (redundant mesh)	Medium	Small (compressed)
Validation	None	None	Built-in
Best for	Simple single-material prints	Multi-color rendering	Everything else

G-code: the printer’s actual instructions

None of the formats above tell the printer what to do directly. That’s G-code’s job.

G-code originated in the 1950s at MIT for CNC machine control. A line like G1 X10 Y20 F3000 tells the machine: move linearly to position (10, 20) at 3000 mm/min. In 3D printing, G-code also handles temperatures, fan speeds, and extrusion rates through M-codes.

Your slicer takes the 3D model (STL, 3MF, whatever) and generates G-code specific to your printer. Because every printer has different motor steps, nozzle sizes, and thermal properties, G-code is rarely portable between machines. It’s always the last step in the pipeline.

STEP: when you need real geometry

STEP (ISO 10303) stores actual mathematical surfaces - planes, cylinders, NURBS patches - instead of triangle approximations. Think of it as SVG for 3D. A cylinder in STEP is “cylinder, radius 5, height 10” regardless of display resolution. In STL, that same cylinder is 124 triangles at low resolution or 1,020 triangles at high resolution.

This matters for CNC machining and injection molding, where CAM software needs to know that an edge is truly circular to generate proper toolpaths. It also matters for transferring models between CAD systems like SolidWorks and Fusion 360 without losing precision.

PrusaSlicer added direct STEP slicing in 2022, generating toolpaths from the original geometry instead of a triangulated approximation. This produces smoother curves on the final print.

OpenSCAD can’t export STEP natively because its internal representation is mesh-based. Once you render, the parametric information is gone. If your workflow requires STEP output, you’ll need a B-Rep tool like CadQuery or FreeCAD. We covered why we chose OpenSCAD despite this limitation - for AI-assisted modeling and 3D printing, the STL/3MF output path works well.

The rest: AMF, IGES, FBX, PLY, VRML

A few more formats you might encounter:

AMF (Additive Manufacturing Format, 2011) was designed as “STL 2.0” by ASTM International. It supports curved triangles and multiple materials through XML. Technically, it’s more capable than 3MF for describing curved surfaces. But the committee didn’t get enough buy-in from printer manufacturers, and when 3MF arrived with Microsoft and HP backing, the industry went that direction instead. AMF is rarely used today.

IGES (Initial Graphics Exchange Specification, 1980) was one of the first cross-platform CAD exchange formats, developed for the US Air Force. It’s been mostly replaced by STEP but still shows up in legacy aerospace files.

FBX is Autodesk’s format for animation and game engines (Unity, Unreal). It supports rigging, animation, and textures but isn’t designed for manufacturing. You’d convert it to OBJ or 3MF before printing.

PLY (Stanford, 1990s) was built for 3D scanner data. It’s like STL but with per-vertex color, which makes it useful for photogrammetry and medical scanning.

VRML (1994) was the original web-based 3D format. Some slicers still accept it because it handles material properties like reflectivity, but it’s niche.

Which format should you use?

For most 3D printing: 3MF if your slicer supports it, STL if it doesn’t. 3MF is better in every measurable way, but STL still works for simple prints.

For multi-color prints: 3MF (integrated) or OBJ (if your toolchain requires it).

For CNC or injection molding: STEP.

For game engines or animation: FBX or glTF.

For AI-generated models via ModelRift: we generate OpenSCAD code and export to good old STL (with 3MF planned support). The AI writes the parametric code, and you get a ready-to-print mesh.