STL and OBJ are two of the most common 3D file formats in existence. If you have ever downloaded a 3D model, exported from a CAD program, or prepared a file for 3D printing, you have almost certainly encountered both. They look similar at first glance since both store 3D geometry as collections of polygons, but they differ in important ways that affect what you can do with the file and how it will look when rendered. Understanding these differences helps you choose the right format for the task at hand and avoid wasting time with conversions and lost data.
STL: Triangles and Nothing Else
STL stands for stereolithography. The format was invented in 1987 by 3D Systems for their stereolithography 3D printing machines, and it became the de facto standard for 3D printing data exchange. Its longevity in the 3D printing world is remarkable: nearly four decades after its creation, STL remains the most widely used format for transferring models from CAD software to slicers.
What STL Stores
An STL file stores a mesh made entirely of triangles. Each triangle is defined by three vertex positions (x, y, z coordinates) and a single face normal vector. That is it. There are no materials, no colors, no textures, no UV coordinates, no vertex normals, no groups, no object names, and no unit information. The format represents pure geometry and nothing more.
STL files come in two variants: ASCII and binary. ASCII STL files are human-readable text files where each triangle is spelled out with explicit "facet normal", "outer loop", "vertex", and "endfacet" keywords. Binary STL files pack the same information into a compact binary structure: an 80-byte header, a 4-byte triangle count, and then 50 bytes per triangle (12 bytes for the normal, 36 bytes for three vertices, and 2 bytes for an attribute field that is almost never used). Binary STL files are typically 80 percent smaller than their ASCII equivalent and load much faster.
STL's Limitations
The most significant limitation of STL is the complete absence of material and color information. Every triangle in an STL file is the same undefined material. When you open an STL in a viewer, the software assigns a default color (usually grey) because the file itself contains no color data. This is fine for single-material 3D printing where the printer uses one color of filament, but it is a severe limitation for visualization, rendering, and multi-color printing.
STL also stores no texture mapping coordinates (UVs), which means you cannot apply texture images to an STL surface. There are no vertex normals beyond the per-face normals, so smooth shading requires the viewer to compute vertex normals by averaging adjacent face normals at load time. There is no support for polygon faces with more than three vertices; everything must be triangulated before export.
The format does not store unit information. The numbers in the file are dimensionless. Whether they represent millimeters, inches, or meters depends entirely on convention and the software reading the file. This is the root cause of the endemic scale problems in 3D printing where models come out the wrong size.
OBJ: Geometry Plus Materials and Textures
OBJ was developed by Wavefront Technologies in the late 1980s as a general-purpose 3D model interchange format. Unlike STL, which was designed specifically for sending geometry to a 3D printer, OBJ was designed for transferring complete 3D scenes between different modeling and rendering applications. This broader scope means OBJ stores significantly more information than STL.
What OBJ Stores
An OBJ file stores vertex positions, texture coordinates (UVs), vertex normals, and face definitions. Faces can be triangles, quads, or arbitrary polygons. Each face can reference different vertex, texture, and normal indices, allowing smooth shading and texture mapping to be defined precisely per-face.
Material information is stored in a companion MTL (Material Template Library) file, referenced from the OBJ file via a "mtllib" directive. The MTL file defines named materials with properties like ambient color, diffuse color, specular color and intensity, opacity, and references to texture image files. An OBJ model can have multiple materials assigned to different groups of faces within the same file.
OBJ files also support vertex colors (an unofficial but widely supported extension), named object groups, smoothing groups for controlling where smooth shading transitions to flat shading, and free-form geometry like NURBS curves and surfaces (though this feature is rarely used in practice).
OBJ's Advantages Over STL
The ability to store materials and textures is OBJ's primary advantage. A textured character model, a colored architectural visualization, or a product render with different material regions can be stored as an OBJ with full visual fidelity. When you open the OBJ in a viewer (along with its MTL file and texture images), you see the model with correct colors, textures, and material properties.
Vertex normals in OBJ allow precise control over smooth shading. You can define exactly which edges are smooth and which are hard (sharp) by controlling the vertex normal values per face. STL files do not provide this level of control, leaving smooth shading entirely up to the viewing application's heuristics.
Polygon support beyond triangles means OBJ files can store quads and n-gons, preserving the original mesh topology from the modeling application. This matters for subdivision surface workflows and for maintaining clean edge flow in character and product models.
Side-by-Side Comparison
- Geometry type: STL stores only triangles. OBJ stores triangles, quads, and arbitrary polygons.
- Materials: STL has none. OBJ supports full Blinn-Phong materials via MTL files.
- Textures: STL has no texture support. OBJ stores UV coordinates and references texture images.
- Vertex colors: STL has no color data. OBJ supports per-vertex colors (unofficial extension).
- Normals: STL stores one normal per face. OBJ stores per-vertex normals for smooth shading control.
- File structure: STL is a single file. OBJ is typically three or more files (.obj + .mtl + textures).
- File size: Binary STL is compact. ASCII OBJ is larger for equivalent geometry. Binary STL is usually smaller than OBJ for pure geometry.
- Units: Neither format stores explicit unit information.
- Animations: Neither format supports animations.
- 3D printing: STL is the universal standard accepted by all slicers. OBJ is supported by some slicers but is less common.
When to Use STL
STL is the right format when your primary goal is 3D printing. Every slicer application accepts STL files. Every 3D printing service bureau accepts STL files. The format is simple, universally compatible, and contains exactly the information a 3D printer needs: triangle geometry and nothing else.
STL is also appropriate when you only need to convey geometry without any visual appearance information. Sharing a mechanical part for fit checking, sending geometry for structural analysis, or storing a mesh for computational geometry processing are all situations where STL's simplicity is an advantage rather than a limitation.
Use STL when:
- Sending files to a 3D printer or slicer application
- Uploading to a 3D printing service like Shapeways, Sculpteo, or JLCPCB
- Sharing pure geometry without material or texture information
- Maximizing compatibility with the widest range of tools
- Generating mesh data programmatically with minimal complexity
When to Use OBJ
OBJ is the right format when visual appearance matters. If your model has textures, multiple materials, or per-vertex colors that need to be preserved in the exported file, OBJ can store that information while STL cannot. Product visualization, architectural rendering, game asset exchange, and digital art portfolios all benefit from OBJ's material and texture capabilities.
OBJ is also the better choice when mesh topology matters. If you are passing a model between applications that use subdivision surfaces, the quad-based topology preserved by OBJ gives a better result than the fully triangulated output of STL.
Use OBJ when:
- Transferring textured models between 3D applications
- Preserving material information across software boundaries
- Maintaining quad and polygon topology for subdivision workflows
- Exchanging models with older software that lacks GLTF support
- Working with photogrammetry outputs that include texture maps
View Both Formats
GeometryViewer supports both STL and OBJ files with full material and texture rendering. Drop either format into the viewer to see the difference firsthand.
Open STL ViewerFile Size Comparison
For pure geometry without materials, binary STL is typically the most compact option. A model with 100,000 triangles produces a binary STL file of approximately 4.9MB (100,000 triangles times 50 bytes each, plus 84 bytes of header). The same geometry exported as an ASCII OBJ with shared vertices will be in the range of 5 to 8MB depending on vertex sharing efficiency and the number of decimal places in the coordinate values.
However, when materials and textures are included, the comparison changes. The OBJ file itself stays roughly the same size, but the texture images (which are separate files referenced by the MTL) can add tens or hundreds of megabytes depending on texture resolution. STL cannot store this information at all, so the comparison becomes moot: you use OBJ (or GLTF) because you need the visual data that STL cannot carry.
The Modern Alternative: GLTF
It is worth noting that both STL and OBJ are showing their age. For new projects that need materials, textures, and compact file sizes, GLTF (specifically the binary GLB variant) is increasingly the better choice over OBJ. GLTF offers PBR materials, animation support, single-file packaging, and significantly better compression. For 3D printing, STL remains dominant, though the newer 3MF format is gradually gaining adoption with its support for colors, materials, and build metadata.
Both STL and OBJ continue to work perfectly well for their respective strengths, and both are fully supported in GeometryViewer. But if you are starting a new project and wondering which format to standardize on, consider STL for 3D printing workflows and GLTF for everything else.