3D File Formats Explained: GLB, glTF, FBX, OBJ, STL & More

The confusion that wastes everyone's afternoon

Someone sends you a 3D model. You double-click it and… nothing opens, or the wrong app launches, or it opens grey and textureless. You try an "online 3D viewer," and it either rejects the file or asks you to upload a model you'd rather keep private. The root of almost all of this pain is a single misunderstanding: the file a 3D app saves is not the file you share. Get that distinction right and 3D files stop being mysterious.

Every 3D tool has a native save format built for itself — Blender's .blend, Cinema 4D's .c4d, 3ds Max's .max, Unreal's .uasset. These are optimised for one program to reload its own work, complete with that program's internal state. They are effectively private. What travels between tools, and onto the web, is a small set of interchange formats — glTF, FBX, OBJ, STL and a few others — that any program can read and write. Our free 3D model viewer opens all of the common interchange formats directly in your browser, with materials, animation and scene inspection, and nothing ever leaves your device. This guide explains the whole landscape so you always know which format to ask for and why.

Why .blend and .uasset can't open in a browser (or anywhere else)

Let's kill the most common request first, because the answer saves hours. A .blend file is not a model — it is a snapshot of Blender's memory: its objects, modifiers, node graphs, UI layout, and undo history, serialised in a structure that changes between Blender versions. There is no published, stable specification you could write a reader against, and even opening a .blend from a slightly different Blender version can behave differently. No browser library parses .blend, and it isn't an oversight — it's genuinely impractical.

Unreal Engine's .uasset and .umap are the same story, more so: they are proprietary, engine-version-locked, often "cooked" (pre-processed for a specific platform) binary blobs tied to Unreal's object system. They only make sense inside the exact engine build that created them. Trying to open one outside Unreal is a non-starter for any tool, browser-based or desktop.

The fix is always the same and it's easy: export. In Blender, File → Export → glTF 2.0 (.glb) gives you a portable file that opens anywhere in seconds. In Unreal, right-click an asset → Asset Actions → Export, or use the glTF/FBX exporter. From that moment your model is a normal, shareable, viewable file. So whenever someone says "here's the Blender file," the right reply is "can you export a GLB?" — and the rest of this guide is about knowing which export to ask for.

The format cheat sheet

All seven open in the viewer. The rest of this article is the "why" behind the table — the details that decide which one you actually want.

glTF / GLB — the one to default to

glTF (GL Transmission Format) was designed from scratch for efficient delivery and display, and it has become the web's native 3D format — the Khronos Group nicknames it "the JPEG of 3D." It stores everything a modern viewer needs: meshes, physically-based (PBR) materials that respond to lighting realistically, textures, skeletal and morph animation, cameras and the full scene hierarchy. Crucially, it supports Draco and meshopt compression, which can shrink geometry dramatically — the difference between a 60 MB and a 6 MB model with no visible quality loss.

The one wrinkle worth understanding is glTF versus GLB. Plain .gltf is a JSON file that points to companion files — a .bin holding the geometry, plus image files for textures. Move the .gltf without its friends and it opens empty. .glb solves this by packing the JSON, the binary and the textures into one self-contained file — which is why GLB is the right choice for sharing and for web viewers. Keep loose .gltf when you're actively editing textures as separate images; ship GLB when you're done. Our viewer decodes Draco- and meshopt-compressed glTF through bundled WebAssembly decoders, so even aggressively optimised web models open quickly and locally.

FBX — the animation and game workhorse

FBX (Filmbox, now owned by Autodesk) is the format the games and film industries have leaned on for two decades. Its strength is rich animation and rigging data — skeletons, skinning, blend shapes, multiple takes — which is why character artists and game developers pass FBX between Maya, 3ds Max, Blender, Unity and Unreal constantly. If a model has a walk cycle or a rigged character, FBX is often how it travels.

Its weaknesses are the flip side of its history: FBX is proprietary and its internals have drifted across versions, so material translation between tools can be inconsistent, and files are larger than glTF. For pure web display, exporting glTF usually gives cleaner materials and smaller files. But FBX remains everywhere, so a good viewer must read it — ours does, including embedded animations, which you can scrub with the timeline. If you're comparing FBX against glTF for a web-bound project, glTF wins on size and material fidelity; FBX wins when a complex rig has to survive a round trip through Autodesk tools.

OBJ, STL, PLY, 3MF and DAE — the specialists

OBJ is the plain-text elder statesman: almost every 3D tool since the 1990s reads it. It stores geometry and texture coordinates, with materials described in a companion .mtl file that in turn points to texture images. That three-file structure (.obj + .mtl + images) is exactly why OBJ models so often appear flat grey — the model loaded but its material file didn't come along. Load them together and colour returns. OBJ has no animation and no PBR, but for a static prop it's bulletproof.

STL is the 3D-printing standard, and it is deliberately dumb: nothing but a list of triangles, no colour, no units, no materials. That simplicity is a feature for slicers. If you're checking a model before printing, STL is what you'll usually have — and seeing it in a viewer first catches non-watertight geometry and wrong scale before you waste filament.

PLY comes from the 3D-scanning world and adds per-vertex colour, which makes it common for photogrammetry scans and point clouds. 3MF is the modern answer to STL's limitations for printing — it carries colour, multiple objects and print settings in one tidy package, and it's increasingly the default from newer slicers. DAE (Collada) is an older XML interchange format that predates glTF's dominance; you still meet it exported from tools like SketchUp, and it can carry materials and animation.

The practical takeaway: you rarely choose these — you receive them. A scan arrives as PLY, a printable part as STL or 3MF, an old asset as DAE. What matters is being able to open whatever lands in your inbox without hunting for the specific app that made it. That's exactly the gap a universal browser viewer fills.

Exporting cleanly: a short checklist

Viewing without the download-an-app tax

Historically, opening a stray 3D file meant installing a heavyweight application — or worse, uploading a possibly-confidential model to some free web service whose privacy policy you never read. Neither is necessary anymore. Modern browsers include a full GPU pipeline (WebGL, and increasingly WebGPU), so a web page can render 3D at real-time speeds using your graphics card, with heavy parsing offloaded to WebAssembly. That's the technology our 3D viewer is built on: drag a file in and it renders locally with PBR materials and shadows, a scene tree for showing and hiding parts, animation playback, and live geometry statistics — and because it all runs in the tab, your model is never uploaded. You can even use it offline once the page has loaded.

The same browser-native, nothing-uploaded philosophy runs through our other tools — the video editor, image converter and PDF studio — so once a 3D file is open you have a whole workshop next door for the screenshot, the recording, or the documentation that usually follows.

Reading a model like an inspector

Opening a file is step one; knowing what you're looking at is the real skill, and a good viewer surfaces the things that matter. The first number to check is the triangle count. A prop meant for a web page or a game should usually sit in the thousands to low hundreds of thousands of triangles; if a simple object reports several million, someone forgot to apply a subdivision modifier or decimate the mesh before exporting, and it will drag performance everywhere it's used. The viewer's live stats — triangles, vertices, meshes and draw calls — make this obvious at a glance.

The second habit is switching shading modes. Wireframe reveals topology: are the polygons evenly distributed, or is detail wasted where nobody will see it? Surface normals shading paints each face by the direction it points, which instantly exposes flipped or inconsistent normals — the cause of those baffling "some faces are invisible or black" glitches. Toggling smooth versus flat shading tells you whether the model was authored with proper smoothing groups. None of this requires opening the source file in its native app; it's all readable from the exported mesh in a few seconds.

Finally, use the scene tree to understand structure. Hiding and showing individual parts reveals how the model is organised — one giant merged mesh, or a tidy hierarchy of named objects — which tells you how easy it will be to work with downstream. A quick pass through the hierarchy, the stats and the wireframe turns "here's a file" into "here's exactly what I'm dealing with," and it's the fastest quality check in 3D that doesn't involve launching a heavyweight editor.

Frequently Asked Questions