If you have ever been sent a folder of 3D files and had no idea which one to open, you are in good company. Most brands commission 3D work without ever being told what the deliverables actually contain, and the result is predictable: a beautiful model that will not load on your website, will not print, or arrives with no textures at all.
This is 3D file formats explained for people who commission the work rather than build it. No jargon, no maths, just what each format stores, what it cannot store, and a simple decision table you can use before you sign off a project brief. A comparable breakdown sits on unity3d.com.
First, what is actually inside a 3D file?
A 3D file is a container. Different containers hold different things, which is the single reason format choice matters. Here are the five layers of data a 3D file may or may not carry:
- Geometry – the mesh itself, made of vertices, edges and faces. Every 3D format stores this.
- Materials and textures – colour, roughness, metalness, normal maps, transparency. Some formats embed these, some reference external image files, some ignore them entirely.
- UVs – the flat map that tells textures where to sit on the model. Without UVs, textures cannot be applied properly.
- Rigs and skinning – the skeleton that lets a character or mechanism move.
- Animation – keyframes, transforms, morph targets, camera moves.
There is also scene data: object hierarchy, naming, units, pivot points, lights and cameras. This sounds like housekeeping until a model arrives 1000 times too large because one file assumed metres and the other assumed millimetres.
Meshes versus CAD: the split nobody explains
Broadly there are two families of 3D file. Polygon mesh formats (OBJ, FBX, STL, glTF) describe a surface as thousands of flat triangles or quads. BREP or CAD formats (STEP, IGES, 3DM) describe surfaces mathematically, so they stay perfectly smooth at any zoom and carry engineering precision.
Rule of thumb: if the file is going to a manufacturer or engineer, you want CAD. If it is going to a website, renderer, game engine or 3D printer, you want a mesh.

The decision table: which 3D file format should you request?
| Your end use | Ask for this | Also useful | Avoid |
|---|---|---|---|
| 3D product viewer on your website | GLB (binary glTF) | Draco or KTX2 compressed variant | FBX, OBJ, STL |
| AR on iPhone / iPad (Quick Look) | USDZ | GLB for Android and web | OBJ, FBX |
| Game engine (Unity, Unreal) | FBX | glTF, USD, Alembic for cached sims | STL |
| Character or product animation handoff | FBX (with rig baked) | Alembic for non-rig deformation | OBJ, STL |
| 3D printing (FDM or resin) | STL | 3MF if colour or material data matters | glTF, FBX |
| Full colour 3D printing | 3MF or OBJ + textures | VRML/WRL for older machines | STL |
| CNC machining, tooling, engineering | STEP (.stp) | IGES, native CAD file | Any mesh format |
| Passing a static model between 3D apps | OBJ + MTL + texture folder | FBX, glTF | Native files you cannot open |
| Archiving the master asset | Native source file (.blend, .max, .c4d) | USD, plus texture source files | Export-only deliverables |
| Stills and marketing renders | Rendered images (PNG/TIFF/EXR) | Layered PSD for retouching | Raw 3D files with no context |

The four formats you will meet most often
OBJ: the universal translator
OBJ has been around since the late 1980s and almost every 3D application can read it. It is a plain text format describing vertices, faces and UVs. Colour and material information lives in a separate .mtl file, which in turn points at image files sitting alongside it. (via https://fictiv.com)
What OBJ stores
- Geometry and UVs: yes
- Materials: only via a companion .mtl file
- Textures: referenced, never embedded
- Rigs and animation: no
When to request OBJ
When you need a static model to open reliably almost anywhere: a scanned object, a product shell going into a visualiser, a mesh being handed to another supplier whose software you do not know. It is the safest lowest common denominator.
The catch
OBJ files are frequently sent on their own, and then arrive grey and untextured. Always ask for OBJ as a zipped folder containing the .obj, the .mtl and every texture map. File sizes are also large because the data is uncompressed text.
FBX: the animation and pipeline workhorse
FBX is owned by Autodesk and is the default currency of the games and VFX world. It carries far more than geometry, which is why it is the standard handoff to Unity and Unreal.
What FBX stores
- Geometry, UVs and multiple mesh objects with hierarchy: yes
- Materials: yes, though interpretation varies between apps
- Textures: can be embedded (binary FBX) or referenced
- Rigs, skinning, blend shapes: yes
- Animation, cameras, lights: yes
When to request FBX
Any time movement is involved, or the asset is heading into a real-time engine or a motion graphics pipeline. If your agency is producing an animated character, a rigged mechanism or a scene with cameras, FBX is the file to ask for.
The catch
FBX is a proprietary format with several versions, so a file exported from one application may not import cleanly into another. Materials in particular often need rebuilding at the far end. When you commission FBX, ask which FBX version was used and which software it was exported from.
STL: the 3D printing standard
STL stores one thing: the outer surface of a shape as a mesh of triangles. No colour, no texture, no units, no layers. That minimalism is exactly why it has been the default for 3D printing for decades.
What STL stores
- Triangulated surface geometry: yes
- Colour, materials, textures: no
- Units: not defined, so the slicer assumes millimetres
- Rigs and animation: no
When to request STL
Prototyping, rapid manufacture, models sent to a print bureau, prop and packaging mockups. If your only question is “can we print this”, STL answers it.
The catch
STL has no concept of scale, so always confirm intended dimensions in writing. It also needs to be watertight (a closed manifold volume with no holes or flipped faces) or a printer will refuse it. If colour matters, look at 3MF, a modern replacement that carries colour, materials and units in a compressed package.
glTF and GLB: the format built for the web
glTF is often described as “the JPEG of 3D”, and the description is fair. It was designed by the Khronos Group specifically for fast delivery and rendering, and it is the format behind almost every 3D product configurator and web viewer you have used. GLB is the binary version that bundles geometry, materials and textures into one single file.
What glTF/GLB stores
- Geometry, UVs, hierarchy: yes
- PBR materials (physically based, so surfaces react correctly to light): yes, natively
- Textures: embedded in GLB, external in .gltf
- Rigs, skinning and animation: yes
- Compression: Draco for meshes, KTX2/Basis for textures
When to request GLB
Anything that loads in a browser or on a phone: product pages, configurators, web AR, Android AR, interactive campaigns. If your deliverable will be viewed by a customer rather than an artist, GLB is almost always the right answer.
The catch
GLB is a delivery format, not a working format. It is the finished export, so do not treat it as your master asset. And a GLB is only as good as its optimisation: ask for a target file size, ideally under 5 MB for a product model, with texture resolution and polygon count agreed up front.
Worth knowing: the supporting cast
| Format | Best known for | Request it when |
|---|---|---|
| USDZ | Apple AR Quick Look | You want “view in your room” on iOS with no app |
| USD | Large collaborative scenes, studio pipelines | You are building a long term asset library |
| 3MF | Modern 3D printing with colour and units | Multi material or full colour prints |
| STEP (.stp) | Engineering and manufacturing CAD | A factory, toolmaker or engineer is involved |
| Alembic (.abc) | Baked animation and simulation caches | Cloth, fluids or crowd animation moves between apps |
| PLY | 3D scanning, vertex colour, point clouds | Working with photogrammetry or scan data |
| DAE (Collada) | Older interchange, largely superseded | A legacy system specifically asks for it |

What each format stores, at a glance
| Format | Geometry | Textures | PBR materials | Rig | Animation | Single file |
|---|---|---|---|---|---|---|
| OBJ | Yes | Linked | No | No | No | No |
| FBX | Yes | Embed or link | Partial | Yes | Yes | Usually |
| STL | Yes | No | No | No | No | Yes |
| glTF / GLB | Yes | Embedded in GLB | Yes | Yes | Yes | Yes (GLB) |
| USDZ | Yes | Yes | Yes | Yes | Yes | Yes |
| 3MF | Yes | Yes | No | No | No | Yes |
| STEP | Yes (BREP) | No | No | No | No | Yes |
How to write a 3D deliverables clause that saves you money
Most format disasters are contract problems, not technical ones. Put the following into your statement of work before production starts:
- Name the end platform, not the format. “Shopify product page viewer” tells your studio far more than “send me a 3D file”.
- Specify units and real world scale. Millimetres for print and manufacture, metres for web and AR is the usual convention.
- Set a polygon and texture budget. For example, under 150,000 triangles and 2K textures for a web model.
- Set a file size ceiling for anything web facing, and ask for compression to be applied.
- Request the source files as well as the exports. Without the native scene, any future edit means rebuilding from scratch.
- Ask for textures separately in their original resolution, even if they are also embedded.
- Confirm naming conventions so meshes and materials are readable rather than “Object_047”.
- Agree who owns and archives the master asset, and where it lives.
Five mistakes we see most often
- Receiving an OBJ with no .mtl or textures and assuming the model was delivered untextured.
- Sending an FBX to a web developer. Browsers do not read FBX natively, so it has to be converted anyway.
- Sending an STL to a manufacturer who needs a STEP file for machining tolerances.
- Publishing a 90 MB GLB that takes 20 seconds to load on mobile and tanks the conversion rate it was built to raise.
- Only holding export formats, then discovering a year later that no one has the editable scene.

A quick note on file size and web performance
For web and AR, the format is only half the job. A GLB carrying four 4K textures will still be slow no matter how modern the format is. Reasonable targets for a customer facing product model:
- Total file size: 2 to 5 MB, and under 10 MB as an absolute ceiling
- Triangles: 50,000 to 150,000 for most products
- Textures: 1K to 2K, compressed with KTX2 where supported
- Draw calls: keep material count low by merging where visually acceptable
Ask your supplier to test on a mid range Android phone over 4G rather than a workstation on office wifi. It changes the conversation quickly.
FAQ
What is the most widely used 3D file format?
STL remains the most widely used format overall because of the sheer volume of 3D printing, but glTF/GLB is now the standard for web and AR, and FBX dominates games and animation. There is no single winner, only the right tool for each destination.
Is OBJ or glTF better?
They are built for different jobs. OBJ is better for maximum compatibility when passing a static mesh between 3D applications. glTF is better for anything that has to load and render in a browser or on a phone, because it supports PBR materials, animation, embedded textures and compression. For a website, choose glTF or GLB.
Can I convert between 3D file formats?
Yes, and most conversions are routine. The risk is data loss: converting FBX to STL will strip materials and animation permanently, and converting a mesh back to CAD rarely restores true engineering precision. Convert downwards from the richest source file rather than sideways between exports. The piece A Comprehensive Guide of 3D Model Formats makes a good next read.
Why did my 3D model open grey with no colour?
Almost always a missing texture link. Either the .mtl and image files were not supplied alongside the OBJ, the folder structure changed after export, or the format simply does not carry materials (STL and STEP do not). Ask for a GLB or a zipped folder with all dependencies included.
Which format should I use for AR product previews?
Supply both: USDZ for Apple AR Quick Look on iPhone and iPad, and GLB for Android Scene Viewer and web based viewers. Most AR implementations expect the pair, generated from the same optimised source model.
Do I need the native source file if I already have exports?
Yes. Exports are flattened snapshots. The native scene file holds the modifiers, layers, lighting setup and editable history that make future updates fast and cheap. Treat it as part of the asset you paid for.
Not sure what to ask for?
If you are commissioning 3D work and want deliverables that actually work on the platform you are paying to fill, tell us where the asset is going and we will specify the formats, budgets and naming conventions for you before a single polygon is modelled. Get in touch with the team at Points Brighton and we will make sure nothing lands in your inbox that you cannot open.

