STL vs OBJ vs glTF: 3D File Formats Compared
Why the Format You Choose Actually Matters
Pick the wrong 3D file format and you will spend hours troubleshooting missing textures, broken normals, or a slicer that refuses to open your model at all. STL, OBJ, and glTF are the three formats most people encounter, yet they were designed for completely different purposes across different decades. STL was standardized in 1987 for stereolithography machines. OBJ came out of Wavefront Technologies around 1992 as a general interchange format. glTF 2.0 was ratified by the Khronos Group in 2017 specifically for real-time rendering on the web and mobile devices. That 30-year gap between the oldest and newest format explains almost every practical difference between them. A file that works perfectly in PrusaSlicer may look completely wrong in a browser-based 3D viewer, and a model optimized for a game engine may be overkill for a desktop FDM printer. This article breaks down each format by structure, capability, file size, and practical use case so you can make an informed choice before you convert — or before you ask a conversion tool like CocoConvert to do it for you.
STL: The Workhorse of 3D Printing
STL stands for Standard Tessellation Language (sometimes retroactively called STereoLithography). The format represents a 3D surface as a mesh of triangles and nothing else. Each triangle is defined by three vertices and an outward-facing normal vector. There is no color, no texture, no material, no hierarchy — just geometry. Binary STL files store each triangle in 50 bytes: 12 bytes for the normal, 36 bytes for the three vertices, and a 2-byte attribute byte count that most software ignores. A typical 1-million-triangle model in binary STL weighs roughly 50 MB. ASCII STL is human-readable but roughly 5–6× larger for the same mesh, which is why binary is almost always preferred in practice. STL's simplicity is its biggest strength for 3D printing workflows. Every major slicer — PrusaSlicer, Cura, Bambu Studio, Chitubox — opens STL natively without any plugins. When you export from Fusion 360 (File → Export → .stl), you can set the refinement to Fine or Custom and dial in a chord tolerance as low as 0.001 mm, which controls how closely the triangles approximate curved surfaces. Lower tolerance means more triangles and a larger file, but smoother curves on the final print. The format's limitation is equally stark: it cannot carry any visual information. If you need to print a multicolor model or communicate material properties to a downstream system, you need a different format or a sidecar file. There is also no built-in unit definition; a value of 1.0 in an STL file could mean 1 millimeter or 1 inch depending on the exporting application, which causes scale errors that beginners frequently run into when importing into slicers.
OBJ: Geometry Plus Materials, at a Cost
OBJ files are plain-text ASCII by default, listing vertices (v), texture coordinates (vt), normals (vn), and faces (f) as separate line entries. A companion MTL file (Material Template Library) handles material definitions, pointing to external texture image files — typically JPEGs or PNGs. This two-file-plus-textures structure is OBJ's most persistent pain point: send someone just the .obj and they lose all the color information. Zip archives, shared folders, and version control systems all need to bundle the MTL and every referenced texture together, or the recipient sees a flat grey model. Despite that friction, OBJ has excellent software support. Blender, Maya, Cinema 4D, ZBrush, Rhino, and virtually every other 3D application can import and export it. The format supports multiple objects and named groups within a single file, which STL does not, making it useful for scenes with several distinct components. It also supports quads and n-gons in addition to triangles, which matters for subdivision modeling workflows where you want to preserve the original topology before triangulating for rendering or printing. File sizes can be large. A complex architectural model with high-resolution textures might consist of a 200 MB OBJ, a 5 KB MTL, and 800 MB of texture maps. Compression is not part of the spec, though many tools will let you export a compressed .objz variant. OBJ also lacks animation, skeletal rigging, and scene hierarchy support, so it is not suitable for game assets or interactive 3D experiences that need those features. For static, visually rich models that need broad software compatibility, OBJ remains a reasonable choice — just keep all the associated files together.
glTF: The JPEG of 3D Formats
The Khronos Group markets glTF 2.0 as the 'JPEG of 3D' because it is designed for efficient transmission and fast loading, not for editing. The format is JSON-based and can reference external binary buffer files (.bin) and textures, or it can pack everything into a single binary GLB file. GLB is almost always preferable for distribution: one file, no missing assets, typically 20–40% smaller than the equivalent OBJ bundle after the textures are embedded. glTF 2.0 supports physically-based rendering (PBR) materials natively. The core material model uses metallic-roughness parameters, which map directly to what modern rendering engines — Three.js, Babylon.js, Unity, Unreal Engine — expect. A metallic value of 1.0 with a roughness of 0.1 produces a mirror-like chrome surface; a metallic value of 0.0 with a roughness of 0.8 produces a flat matte plastic. These values are stored in the file and render consistently across compliant viewers without any manual material re-assignment. Beyond static geometry, glTF supports morph targets, skeletal animation, multiple camera definitions, scene hierarchy, and extensions for features like transmission (for glass materials) and volume (for subsurface scattering). A product configurator on an e-commerce site, an AR preview in a mobile app, or a character in a browser-based game can all use the same GLB file. The trade-off is that glTF is not an authoring format. You would not model in glTF the way you might work in a native Blender .blend file. Round-tripping a glTF through multiple editing passes tends to degrade the mesh because most exporters triangulate geometry and bake down complex node graphs into PBR textures. For final delivery to web or real-time environments, glTF is excellent. For iterative editing, keep your source files in a native format.
Head-to-Head Comparison: A Practical Reference
The table below summarizes the key differences across six criteria that matter in real workflows. Geometry support: All three formats handle triangle meshes. OBJ additionally supports quads and n-gons. glTF supports triangles and lines (for wireframe use cases). Color and materials: STL has none natively (a non-standard color extension exists but is rarely supported). OBJ uses external MTL files with basic Phong shading parameters. glTF has full PBR materials baked in. Textures: STL — none. OBJ — external image files referenced from MTL. glTF — embedded in GLB or referenced externally; supports base color, normal, metallic-roughness, occlusion, and emissive maps as first-class texture slots. Animation: STL — none. OBJ — none. glTF — full skeletal and morph-target animation. Typical file size for a mid-complexity model (roughly 500k triangles, one material): Binary STL ~25 MB. OBJ + MTL + textures ~35–120 MB depending on texture resolution. GLB ~8–25 MB with compressed textures using KTX2/Basis Universal. Software compatibility: STL is near-universal for manufacturing tools. OBJ is near-universal for DCC (digital content creation) tools. glTF is dominant for real-time and web tools, with growing support in DCC applications. Primary use case: STL → FDM/SLA/SLS 3D printing. OBJ → interchange between modeling and rendering applications. glTF → web viewers, AR/VR, game engines, e-commerce product previews. If you are printing a functional bracket on an FDM printer, export STL. If you are handing off a detailed architectural visualization to a rendering artist, OBJ or a native format like FBX is more appropriate. If you are publishing a product model on a website or sending an AR asset to a mobile developer, GLB is the right choice.
Converting Between Formats: What Works and What Doesn't
CocoConvert handles the most common conversion paths: STL to OBJ, OBJ to STL, OBJ to glTF/GLB, and GLB to OBJ. For straightforward geometry conversions — particularly anything involving STL — the process is reliable because STL carries only triangle data, and that data maps cleanly to the geometry sections of OBJ and glTF. The harder direction is going from a richer format to a poorer one. Converting a textured OBJ to STL will strip all material and texture data because STL simply has no place to store it. CocoConvert will warn you before this happens, but it cannot preserve what the target format does not support. If you need a printable STL from a colored OBJ, you will get the geometry, which is usually exactly what a slicer needs. Converting OBJ to GLB is where things get interesting. CocoConvert will attempt to map Phong-based MTL parameters to PBR equivalents — specifically, the diffuse color maps to base color, and the specular exponent (Ns value in MTL) is used to approximate roughness. This mapping is imperfect. A high-gloss plastic that looks correct in a traditional renderer may appear slightly different in a PBR viewer after conversion. For critical product visualization work, you will get better results re-exporting from the original authoring application (Blender, Maya, etc.) directly to glTF using the native exporter, which has full control over the PBR material setup. One honest limitation: CocoConvert does not currently support animated GLB files. If you upload a GLB with skeletal animation and convert it to OBJ, the animation data is lost and you receive a static mesh at the default pose. We are working on animation-aware conversion, but it is not ready yet. For animated assets, Blender's native glTF exporter (File → Export → glTF 2.0) remains the most reliable tool available.
Choosing the Right Format for Your Project
The decision tree is simpler than it might appear once you anchor it to the end use. If your model is going to a 3D printer, use STL. Nearly every slicer prefers it, the files are compact, and the format's lack of features is irrelevant because printers do not render materials anyway. Export binary STL, not ASCII, unless a specific tool requires the text version. Set your chord tolerance tight enough that curves look smooth at the scale you are printing — for a 200 mm tall model, 0.01 mm tolerance is usually more than sufficient. If your model is going to a rendering artist or needs to pass through multiple DCC applications, OBJ is a safe interchange format. Keep the MTL and all texture files in the same folder and name them clearly. Avoid spaces in filenames — several older parsers choke on them. If the model is complex, consider FBX instead, which handles scene hierarchy and animation better than OBJ, though FBX is a proprietary format with its own quirks. If your model is going to the web, an AR application, a game engine, or any real-time viewer, use GLB. The single-file format eliminates missing-asset problems, the PBR material model renders consistently across platforms, and modern compression (Draco mesh compression, KTX2 textures) can shrink a 50 MB OBJ bundle to under 5 MB without visible quality loss. Three.js loads GLB in three lines of code; most game engines import it with drag-and-drop. When in doubt about what a client or collaborator needs, ask them what software they are using on their end. The answer will tell you the format immediately. A Cura user needs STL. A Blender artist can take OBJ or GLB. A web developer building a product page almost certainly wants GLB. Matching the format to the tool at the destination end saves everyone time.