How to Export a 3D Model: GLB, FBX, OBJ, STL (2026 Guide)

Export is the last 10% of the 3D workflow and the part that breaks the most. Pick the wrong format and your textures vanish, your model lands sideways in the target app, or your slicer refuses to open it. This guide is about picking correctly the first time.

I'm on the Trify3D team and the export behavior described here comes straight from our studio export code, the actual useExportModel hook that runs when you click export, not a format wishlist. Trify3D's studio exports four formats natively: GLB, glTF, OBJ, STL. FBX and USDZ are not native exports; I'll cover the honest path to those below. Last updated 2026-07-03.

Pick by downstream tool, not by file size

The format decision is really a question of "what is the next program that opens this file?" Work backwards from there.

The rule I use: if the next tool is a browser or game engine, GLB. If it's a slicer, STL. If it's an old pipeline that only speaks OBJ, OBJ. glTF only when I need to inspect the raw structure.

GLB: the default for anything real-time

GLB is a single binary container holding geometry, animation, and PBR textures in one file. It is the format three.js, Babylon.js, Google Earth, and most AR toolchains consume natively. If you don't have a specific reason to pick something else, pick GLB.

Two things worth knowing:

• Draco compression. GLB supports mesh compression via Draco, which can shrink geometry 5-10x. The catch: the loader on the other end must support Draco decoding. Modern three.js does; some older viewers and custom pipelines don't. If your model loads as an invisible blob, Draco is the first thing to check.
• Materials are PBR. GLB carries metal/rough PBR materials. If your source used specular workflows, expect the conversion to shift the look slightly. Not a bug; different lighting model.

In our export path, GLB is the cleanest case: one async call, one binary blob, one download. No zip, no sidecars.

glTF: the unzipped form, ships as a folder

glTF is the human-readable sibling of GLB. Same data, but split across multiple files: a .gltf JSON describing the scene, a .bin holding the geometry bytes, and separate image files for textures.

You rarely want glTF as a deliverable: it is fiddly to move around because of the multiple files. It's useful when:

• You want to inspect or hand-edit the scene JSON
• You're debugging a material issue and need to see the raw texture references
• A specific tool consumes glTF but not GLB (rare)

Because a multi-file download is awkward, our studio exports glTF as a zip containing the .gltf plus its .bin and textures with correct relative paths. Unzip and open the .gltf in any compliant viewer. This trips people up the first time: they expect a single .gltf file and instead get a zip. That's intentional, because the binary and textures can't legally live inside the .gltf JSON.

OBJ: the universal fallback

OBJ is the oldest format still in wide use. Every 3D program reads it. That universality comes with limitations:

• No PBR. OBJ uses a .mtl sidecar with basic Phong-style materials. Metallic/roughness data does not survive; your shiny metal becomes a flat gray.
• Multi-file. An OBJ export is really three things: the .obj geometry, the .mtl material library, and any texture images. Lose the .mtl and your model comes in untextured.
• No animation, no bones. OBJ is static geometry only.

In our export, OBJ ships as a zip with .obj + .mtl so the material references resolve correctly. Reach for OBJ when nothing else works: a legacy pipeline, a CAD viewer, a tool that predates glTF.

One gotcha I hit once: OBJ's coordinate system and winding order differ from glTF. If your model comes in inside-out or rotated 90° on import, that's why; most viewers have a "flip normals" or "fix winding" toggle.

STL: geometry only, for printing

STL stores pure triangle geometry, no color, no materials, no animation. It is the lingua franca of 3D printing; every slicer reads it.

Two flavours:

• Binary STL: compact, the default. What you want for printing.
• ASCII STL: human-readable, ~5x larger. Only useful for debugging.

STL is the simplest export because there is nothing to get wrong except the geometry itself. The one thing to verify before printing is that the mesh is manifold (watertight, no holes, no flipped normals). Non-manifold STLs slice badly or fail entirely. Run a mesh repair pass (Blender's "Print 3D Toolbox" or Meshmixer) before exporting if your model came from reconstruction.

The honest path to FBX

FBX is the Autodesk interchange format and the default for a lot of game engines and animation pipelines. It is not a format Trify3D exports natively, and I'd rather say that plainly than imply otherwise.

The reliable path:

1. Export your model as GLB from the studio.
2. Import the GLB into Blender (free, imports GLB cleanly).
3. Export as FBX from Blender (File → Export → FBX).

Blender's FBX exporter is the de facto standard; it preserves materials, armatures, and animation well enough that Unity, Unreal, and Maya all accept it without complaint. This is also the workflow I recommend if you need USDZ (Apple's AR format): Blender can export USDZ directly, or you use Apple's usdz_converter on an OBJ.

The reason Trify3D doesn't ship FBX directly is that a correct FBX export for animation pipelines needs skinning and bone data that single-view image-to-3D output doesn't produce meaningfully. Better to be honest about the GLB→Blender→FBX handoff than ship a half-baked FBX.

A note on coordinate systems

The silent killer of 3D exports. glTF and GLB are right-handed with +Y up. Blender is right-handed +Z up. Unity is left-handed +Y up. Unreal is left-handed +Z up. OBJ is right-handed +Z up.

Translation: a model that looks correct in one tool may land sideways, mirrored, or at the wrong scale in another. Most importers auto-detect up-axis from the format, but not always. If your exported model is wrong, before blaming the exporter, check:

• Up-axis setting on the importer (Y vs Z)
• Unit scale (meters vs centimeters; glTF is meters, FBX is often centimeters)
• Winding order / normals flip

This is the single most common "my export is broken" cause, and it's almost never the exporter's fault.

Which format, then?

For most people, most of the time: GLB. It's the one that just works across the modern stack. Use STL when printing, OBJ when forced to, glTF when debugging. FBX via Blender when a pipeline demands it.

If you're exporting a model you just generated, the image to 3D workflow covers what happens upstream; the format choice is downstream of getting a mesh worth exporting in the first place.