A short history
STL stands for stereolithography. The format was created for 3D Systems in 1987, during the early years of commercial SLA printing, as a simple way to move geometry from CAD software into printing workflows.
That simplicity is the whole idea: an STL file stores only the outer surface of an object as a list of triangles. There are no curves, no feature history, no materials, no assemblies, and no guaranteed units. That is why STL became the universal fallback format for 3D printing, and also why it now feels limited next to newer formats like 3MF.
ASCII vs. binary
STL exists in two encodings.
ASCII STL is plain text. Each triangle is written with keywords such as facet normal, outer loop, and vertex. It is easy to inspect, debug, or generate with simple scripts, but it becomes very large for detailed meshes.
Binary STL is the format most tools write by default. It starts with:
- an 80-byte header
- a 32-bit triangle count
- one 50-byte record for every triangle
Each binary triangle record contains:
- 12 bytes for the normal vector
- 36 bytes for the three vertices
- 2 bytes for the attribute byte count
Those last two bytes were never standardized in a useful way. Some software uses them, or the header, for proprietary color data, but support is inconsistent. In practice, STL should still be treated as a geometry-only format.
One small gotcha: binary STL files are sometimes mistaken for ASCII if their header starts with the word solid. Robust parsers usually inspect the full structure instead of trusting the first few bytes.
How geometry is stored
An STL model is a collection of facets. Each facet is one triangle described by:
- one normal vector
- three 3D vertex positions
The normal is meant to point outward. The triangle vertices are also expected to follow the right-hand rule: when viewed from outside the object, their order should be counter-clockwise. Many viewers recompute normals from the vertices, but mismatches between stored normals and vertex order are still a useful sign that a mesh may be broken.
Unlike indexed mesh formats, STL does not share vertices between triangles. Every triangle stores its own three coordinates even when neighboring triangles touch the same corner. That duplication makes files larger and removes explicit topology from the file. Software has to infer adjacency later by comparing floating-point coordinates.
STL also stores no units. A coordinate value of 10 might mean 10 mm, 10 inches, or 10 cm depending on the exporter and the tool that opens it. Historically, early STL documentation also assumed all coordinates were positive, but modern software generally accepts negative coordinates without trouble.
What makes a valid STL mesh
For 3D printing, the triangle soup still has to describe one coherent boundary. In practice, that means:
- adjacent triangles should meet edge-to-edge
- the surface should be watertight
- normals and winding should point consistently outward
- triangles should not self-intersect
Older STL documentation described this as a vertex-to-vertex rule: a triangle edge should connect cleanly to the edge of its neighbor, not end halfway across another triangle.
When these conditions fail, slicers can no longer reliably tell what is inside the object and what is outside. That leads to the classic STL repair problems: holes, flipped normals, non-manifold edges, duplicate facets, and other geometry errors.
When to use STL
STL is still the safest choice when compatibility matters more than richness. If you want a mesh that almost every slicer, CAD tool, and online print service can open, STL remains the lowest common denominator.
It is a weaker choice when you need:
- explicit units
- multiple objects in one well-structured package
- colors, textures, or materials
- metadata or print settings
- compact storage for complex meshes
For those cases, 3MF is usually the better modern default. It keeps units explicit, supports richer metadata, avoids STL's "every triangle is isolated" design, and is better suited to ready-to-print workflows.
Viewing STL in the browser
STLViewer parses both ASCII and binary STL directly in the browser using Three.js. No upload is required for a quick preview, so the file stays on your device unless you explicitly decide to share it.
For sharing, we upload the file to Cloudflare R2 behind a short-lived presigned URL and return a unique share link. Share links are private: they are not indexed by search engines and are not listed anywhere public on the site.