How to convert glTF to STL
- Drop the .glb or a self-contained .gltfA .glb carries its buffers and images inside one file and always loads. A .gltf loads only when its buffers are embedded; if it points at a neighbouring .bin, the browser cannot resolve that relative path from a single dropped file. The bytes stay in the tab — there is no upload step, queue or account.
- Let the decoders handle compressionIf the asset uses Draco or meshopt, the reader fetches the matching WebAssembly decoder and decompresses in memory. This is the only network request involved, and it happens only for compressed files.
- Set the scale before exportingglTF coordinates are metres; STL numbers are read as millimetres. Multiply by 1000 in the workspace scale control for a real-world-sized model, or leave it at one if your asset was already authored in millimetres as a game-engine trick.
- Convert to STLEvery mesh under every node is transformed into world space and written as unshared triangles: an 80-byte header, a 32-bit facet count and 50 bytes per facet. Materials, skins, cameras, lights and animations have no representation and are dropped.
- Check the result in the slicerConfirm the bounding box dimensions and let the slicer report holes and non-manifold edges. Game assets are often single-sided shells with no wall thickness, which look correct in a viewer and are unprintable as they stand.
What happens when glTF becomes STL
JSON, buffers and the single-file problem
The glTF specification separates the description from the data. The .gltf document lists nodes, meshes, accessors and materials, while the actual vertex arrays live in buffers that are either embedded as data URIs or referenced as sibling files, and images follow the same rule. A .glb container wraps all of it into one binary blob. In a browser file picker only the selected file exists, so a .gltf referring to scene.bin has no way to fetch it. That is the single most common failure with this format, and it is fixed on the export side by choosing GLB or embedded buffers.
Scene graph in, triangle soup out
glTF nodes form a hierarchy with local transforms, meshes hold primitives, and primitives can be split by material. STL has none of that: its record stream has no name, no transform and no material slot. The exporter therefore traverses the scene, applies every parent transform to the vertices, and appends all primitives into one list. Skinning is not evaluated, so a rigged character is exported in its rest pose; animation samplers are ignored, so the file represents one static moment. Parts that were separate become one shell, and intersecting parts become a self-intersecting shell.
Why the unit mismatch is structural
glTF mandates metres and a right-handed coordinate system with +Y up. STL mandates nothing: it is bare 32-bit floats, and the printing ecosystem has settled on millimetres with +Z up. A correctly authored two-metre doorway is therefore written as coordinates around 2.0, and a slicer reads that as two millimetres. The scale control exists precisely for this conversion; apply 1000 for metre-authored assets. Orientation is a separate decision — STL has no declared up axis, so a Y-up character usually needs a ninety-degree rotation about X in the slicer.
Compression is decoded, not preserved
Draco and meshopt reduce the size of the source by quantising and compressing vertex data. Both are decoded before the scene is built, so the geometry reaching the STL exporter is full-precision as far as the decoder reconstructs it. STL itself has no compression mechanism, which is why a small compressed glTF can produce a much larger STL: the download size reflects triangle count at 50 bytes each, not the size of the file you dropped.
glTF vs STL
| glTF / GLB source | Binary STL output | |
|---|---|---|
| Container | JSON plus buffers, or one binary .glb | Flat facet stream, no packaging |
| Geometry | Indexed primitives with optional Draco / meshopt | Unshared triangles, 50 bytes each |
| Units | Metres by specification | None; slicers assume millimetres |
| Up axis | +Y | Unspecified; printing convention is +Z |
| Materials | PBR with textures, normal and emissive maps | None |
| Structure | Node hierarchy, named meshes, primitives | One merged triangle list |
| Animation | Samplers, skins and morph targets | One static pose |
| Purpose | Real-time rendering and AR | Slicer input |
Supported formats
| Format | Read | Write | Notes |
|---|---|---|---|
| STEP (.step .stp) | Yes | – | ISO 10303 B-rep, AP203 / AP214 / AP242 |
| IGES (.iges .igs) | Yes | – | Entity-based surfaces, up to 5.3 |
| BREP (.brep) | Yes | – | OpenCascade native B-rep |
| STL (.stl) | Yes | Yes | Binary and ASCII triangles, no units |
| OBJ (.obj) | Yes | Yes | v / vn / f records; .mtl references ignored |
| PLY (.ply) | Yes | Yes | Binary position and normal arrays |
| GLB / glTF (.glb .gltf) | Yes | Yes | glTF 2.0, binary or JSON with data URI |
| 3MF (.3mf) | Yes | Yes | OPC/ZIP package, declares millimetres |
| FBX (.fbx) | Yes | – | Binary and ASCII, static mesh only |
| DAE (.dae) | Yes | Yes | Collada scene graph is flattened |
| 3DS (.3ds) | Yes | – | Legacy chunk-based 3D Studio format |
| AMF (.amf) | Yes | – | XML, ZIP-compressed packages supported |
| USDZ (.usdz) | Yes | Yes | ZIP containing a USD stage |
Known limitations and why a conversion can fail
External buffers and textures
A .gltf whose buffers or images are sibling files cannot be completed from a single dropped file. The geometry may appear empty or the load may fail outright. Re-export as .glb, or embed the resources as data URIs in the JSON. This is an input-packaging issue, not a geometry problem, and the preview typically reveals it immediately.
Game assets are not printable by default
Real-time assets optimise for appearance: single-sided surfaces, open shells, intersecting decorative pieces, hair cards and meshes with no thickness. All of that converts faithfully and still fails in a slicer. Use a mesh repair tool, or treat the STL as a starting point rather than a finished solid. The conversion never invents thickness or unions overlapping parts.
Very dense scenes exhaust tab memory
Decoding compression and flattening a large scene happens in a browser tab with a 32-bit WebAssembly address space. A photogrammetry asset with tens of millions of triangles can abort before the export stage. Decimate in the authoring tool, or split the scene by node and convert the part you need.
One file per run
The workspace holds a single scene and writes a single STL. Converting a library of assets means one run each; there is no batch queue in the browser build. The Windows app adds a queue, but the browser page deliberately keeps the flow to one file at a time.
Frequently asked questions
Can I convert on this page itself?
No. This page is the reference for the glTF to STL path, and the conversion itself runs in the workspace that the button above opens, with both formats already selected. Your file is read in that browser tab and the download is written locally, so there is no upload stage in either place. Keeping the documentation and the engine on separate addresses lets file support and detail levels change behind one workspace without breaking the page you are reading.
Why does my .gltf file fail while a .glb works?
Because a .gltf is usually only the JSON half of the asset. Its geometry lives in buffers referenced by relative filename — typically a .bin next to it — and its images are separate PNG or JPEG files. The browser receives the one file you drop and has no folder to resolve those relative paths against, so the buffers never load. A .glb packs the same JSON, buffers and images into one binary container, which is exactly why it works here. If you must keep the .gltf form, re-export with embedded data URIs so the buffers and textures sit inside the JSON itself.
Are Draco and meshopt compressed files supported?
Yes. The reader attaches both a Draco decoder and a meshopt decoder and only fetches the decoder the file actually needs. Draco geometry and meshopt-compressed buffers are decoded inside the tab, so a compressed asset converts like any other. The decoders are WebAssembly modules served from this site, which means the first compressed file in a session needs the page to be online, even though the model itself is never uploaded.
Why is the STL a thousand times too small?
Because glTF stores coordinates in metres by specification and STL declares no unit at all while every slicer reads its numbers as millimetres. A door that is two metres tall in glTF becomes a triangle soup whose highest vertex is 2.0, which a slicer interprets as two millimetres. Nothing in the pipeline silently rescales the model, because that would corrupt assets that were authored with a deliberate unit trick. Use the scale control in the workspace to multiply by 1000 before export, then check the bounding box in the slicer.
What happens to animations, skins and morph targets?
They are not evaluated. The exporter walks the scene as it is loaded, takes each mesh's current vertex positions, bakes the node transforms into world coordinates and writes those triangles. An animated character therefore exports in its rest pose, a skinned mesh exports with its bind pose, and morph-target blends are ignored. STL has no concept of time, joints or blend weights, so there is nowhere to put any of it even if the exporter wanted to.
Do materials and vertex colours survive?
No. A glTF material can carry a base colour texture, metallic-roughness values, normal maps and emissive terms, and the exporter can pass a material to GLB or glTF output but not to STL. The binary STL facet record is twelve floats and a two-byte attribute word that is written as zero, so the downloaded file is one unshaded surface. The on-screen preview still shows the original materials because it renders the loaded scene; that is presentation, not part of the export.
Can I convert a whole scene with several objects?
Yes, but they arrive as one object. glTF nodes, meshes, primitives and their parent transforms are all resolved into world space and concatenated into a single triangle list. Separate parts that were individually selectable in a viewer become indistinguishable neighbours, and if two parts intersect the merged shell is usually non-manifold. If you need the parts kept apart, export each node separately or convert to OBJ, which retains object groups.
References
- Khronos glTF 2.0 specification
- three.js documentation — loaders and exporters
- How this site is built and tested
Related converters
All converters
Last updated: