Understanding 3D File Formats for Computer Graphics

A 3D file format is a specification for how a computer stores a three-dimensional object: its geometry, its surface data, where it sits in a scene, and how it moves. Every 3D package writes its own native format, which is why hundreds of file types exist.

In practice, only a handful matter for commercial work: OBJ, FBX, STEP, STL and glTF. Each one is built for a different job, and knowing which is which prevents avoidable rework.

Proprietary versus neutral formats

3D file formats split into two categories.

Proprietary formats are built into a specific package. Blender writes BLEND. AutoCAD writes DWG. These formats are optimised for the software that made them, so working inside them is fast and lossless. The trade-off is portability. A BLEND file means nothing to a machine running only AutoCAD.

Neutral formats cross that boundary. OBJ, FBX and STL are readable by most 3D software regardless of what created them.

If a model is built in Blender and needs to be opened in AutoCAD, exporting it as OBJ solves the handoff. The studio still works in the optimised native format day to day; the neutral format exists for the moment data has to leave that ecosystem.

The five formats that matter

OBJ

OBJ dates to the 1980s, created by Wavefront Technologies. It’s the simplest format in wide use: pure geometry, no animation, no rigging, no scene data. That simplicity is why it remains the default export for 3D modelling software and a common choice for 3D printing pipelines.

FBX

FBX is a proprietary format originally built by Kaydara, acquired by Autodesk in 2006. It carries geometry, materials, lighting and animation data together, which makes it the standard interchange format for game and entertainment pipelines moving assets between packages like Maya, 3ds Max and Cinema 4D.

Its strength is exactly that breadth: because it preserves rigging, keyframe animation and camera data alongside the mesh, a fully animated scene can move between two different studios’ pipelines without losing the motion work that took the longest to build.

STEP

STEP is the interchange format of choice in CAD. Fusion, AutoCAD and Onshape all read and write it.

Where OBJ and STL describe surfaces as polygon meshes, STEP stores geometry as mathematical NURBS functions, which preserves the precision engineering data needs when it moves between businesses, contractors, and internal departments. That mathematical precision matters most when a design needs to be manufactured to exact tolerance: a mesh-based format approximates a curved surface with flat triangles, while STEP’s NURBS description defines the curve exactly, with no approximation error to compound through a production process.

STL

STL (Standard Tessellation Language, sometimes Standard Triangle Language) encodes a model’s surface as a mesh of triangles. It was built for exactly one purpose: getting geometry to a 3D printer. It carries no colour, texture or scene information, which is precisely why it’s still the format printers expect.

glTF

The Khronos Group released glTF as an open standard in 2015, aimed at the same problem JPEG solved for images: universal, fast-loading compatibility. It’s built for the browser and for AR, handling animation efficiently while keeping file sizes down, which is why web-based product viewers and AR pipelines increasingly default to it over FBX.

Two formats worth knowing beyond the core five

USDZ

Apple built USDZ specifically for AR Quick Look on iOS, based on Pixar’s Universal Scene Description framework. It packages geometry, materials and lighting into a single file a phone can open directly in AR without a dedicated app.

Any brand shipping AR product previews to iOS users needs a USDZ export in the pipeline alongside glTF, because Android and iOS default to different formats for the same job.

3DS

3DS is an older proprietary format from Autodesk’s 3D Studio, predating the more capable 3ds Max native format. It’s largely legacy today, still readable by most packages for backward compatibility, but rarely the first choice for new production work. It’s worth recognising mainly because older asset libraries and archives still hold files in it.

Binary versus ASCII: the format-within-a-format decision

Most of the formats above can be saved as either binary or ASCII (plain text), and that choice matters independently of which format is chosen.

Binary stores data as raw bytes. It’s compact and fast to load, which is why production pipelines default to binary FBX or binary glTF whenever file size or load speed matters, web delivery and AR being the clearest cases.

ASCII stores the same data as human-readable text. Files are larger and slower to parse, but they can be opened in a plain text editor and inspected or hand-edited, which matters for debugging a broken export or checking exactly what data a file actually contains.

Most studios default to binary for delivery and reach for ASCII only when something needs manual inspection.

Matching format to deliverable

A quick reference for the decision that actually gets made on a brief:

• Physical prototyping or 3D printing: STL, because a printer needs geometry only.
• Web-based product viewer or configurator: glTF (binary), for load speed in the browser.
• iOS AR preview: USDZ, because Quick Look expects it natively.
• Android AR preview: glTF, the format most Android AR frameworks default to.
• Animation handoff between studios or packages: FBX, because it carries rigging and keyframe data intact.
• CAD-to-CAD engineering exchange: STEP, for the precision NURBS data preserves.
• General geometry exchange with no animation: OBJ, the simplest common denominator most software reads.

Why the format choice matters beyond the 3D team

A marketing or product team doesn’t need to master file formats to be effective, but understanding what each one is for changes three things.

Fewer wasted conversions. Choosing STL for a printer output or glTF for a web viewer up front avoids reprocessing model data later. A model exported in the wrong format doesn’t just need converting: some formats lose materials or animation on the way, which means requesting new work from the studio rather than a straight export.

Sharper conversations with the studio. When a marketing lead knows that FBX carries animation and STL doesn’t, briefing conversations about “can we get this in a format that plays back correctly” get shorter, because the underlying constraint is understood rather than assumed.

Consistency across channels. Interactive product configurators, AR experiences and print marketing all draw from the same 3D source, but each destination format handles that source data differently.

Knowing which format serves which channel keeps output consistent whether it’s landing on a product page, in a retailer’s AR try-on tool, or in a print catalogue.

What happens when the wrong format gets used

The practical consequence of a format mismatch is worth understanding concretely. Delivering an FBX to a web developer expecting glTF means either a manual conversion step, which can strip material data if not handled carefully, or a re-export from the original 3D scene, which means going back to the studio.

Delivering a mesh-based STL where a manufacturer needed STEP’s precise NURBS data means the manufacturer is now working from an approximation rather than an exact geometric definition, a genuine problem for anything manufactured to tight tolerance. Neither mistake is catastrophic, but both create delays that a correct format choice at the brief stage would have avoided entirely.

The takeaway

OBJ, FBX, STEP, STL and glTF exist because no single format does everything well. OBJ for portable geometry.

FBX for animation handoff. STEP for CAD precision.

STL for 3D printing. glTF for the browser.

Picking the right one at the brief stage, rather than discovering the mismatch after delivery, is the difference between a smooth production pipeline and repeated rework.