FBX File Documentation

Summary

An .fbx file is a 3D model and scene interchange file made by Autodesk FBX (Filmbox). It stores a whole scene — geometry, materials, skeletal rigs, keyframe animation, cameras and lights — so assets can move between Maya, 3ds Max, Blender, Unity and Unreal. Its MIME type is application/octet-stream. View one free in Autodesk FBX Review or Blender.

Technical details

Full nameAutodesk FBX (Filmbox) 3D Interchange File
File extension.fbx
MIME typeapplication/octet-stream
Format type3D scene interchange: geometry, materials, animation, cameras, lights
Category3D image files
DeveloperAutodesk; created by Kaydara in 1996; owned by Autodesk since 2006 (via Alias)
Introduced1996 — Kaydara Filmbox
EncodingBinary or ASCII text
Byte orderLittle-endian (binary form)
Magic numberKaydara FBX Binary  \0 — 21-byte header at offset 0 (binary form only)
SDKClosed-source Autodesk FBX SDK
Open standardNo — proprietary
Related extensions.obj .dae .gltf .glb .3ds .stl .usd .blend
Modern alternativesglTF, USD
SpecificationBlender — FBX binary file format specification
File signature (magic bytes)
4B 61 79 64 61 72 61 20 46 42 58 20 42 69 6E 61 72 79 20 20 00

A binary FBX file begins with the 21-byte ASCII magic Kaydara FBX Binary  \0 at offset 0. Note the two spaces before the trailing NUL. It is followed by the bytes 0x1A 0x00, then a 32-bit unsigned version number at offset 23 stored little-endian (for example 7300 = FBX 7.3, 7500 = FBX 7.5). An ASCII FBX file has no binary magic: it is plain text that starts with a ; FBX ... comment line and an FBXHeaderExtension block.

What is an FBX file?

FBX is a 3D asset interchange format. A single .fbx file can hold an entire scene rather than one object, which is why it became the common currency for moving 3D content between programs. The format was created by Kaydara in 1996 under the name Filmbox. Autodesk acquired it in 2006 when it bought Alias, and it has controlled the format since. Today FBX is the standard way to hand a model off from a digital content creation tool to a game engine, or from one artist’s software to another’s.

The strength of FBX is breadth. Where OBJ carries a static mesh and little else, an FBX file can carry geometry, the materials and textures assigned to it, a skeletal rig with skin weights, keyframed and morph-target animation, and the cameras and lights that frame the scene. That makes it well suited to animated and rigged characters, not just props.

What a scene carries: meshes, rigs, animation, cameras, lights

An FBX file is best understood as a container for a scene graph. The main kinds of data it stores are:

  • Geometry — meshes made of vertices, polygons, normals and one or more UV layers for texturing.
  • Materials and textures — shading definitions and references to image maps applied to surfaces.
  • Deformers and skin — the bone hierarchy plus the skin weights that bind each vertex to bones.
  • Animation — keyframed transforms on nodes, morph (blend-shape) targets, grouped into animation stacks and layers. Older files call these “takes.”
  • Cameras and lights — scene elements with their own transforms and parameters.
  • Connections — the wiring that links objects to their materials, deformers and animation.

Because one file can bundle all of this, an FBX export can reproduce a rigged, animated, textured character in another application in a single step, at least in principle. In practice how faithfully it round-trips depends on how well both programs implement the format.

Binary and ASCII encodings

FBX comes in two encodings that use the same logical structure. The binary form is compact and by far the most common; it is what most tools export by default. The ASCII form is plain text that stores the same node tree in a readable, indented syntax. ASCII FBX is larger and slower to parse, but it is useful for debugging, for diffing two exports, or for inspecting exactly what a program wrote. Both forms describe an identical tree of nodes and properties, so a reader that understands the model can support either.

The 27-byte binary header and version number

A binary FBX file opens with a fixed 27-byte header. The first 21 bytes are the ASCII magic string, with two spaces before the terminating NUL. Two marker bytes follow, then a 32-bit unsigned version number stored little-endian:

Offset  Size  Field
0       21    Magic: "Kaydara FBX Binary  \x00"  (two spaces, then NUL)
21       2    [0x1A, 0x00]
23       4    uint32 version (little-endian)  e.g. 7300, 7400, 7500

The version number decodes directly: 7300 is FBX 7.3, 7400 is 7.4, and 7500 is 7.5. That number matters, because it changes how the rest of the file is parsed, as the next section explains. After the header comes a single top-level node record with an empty name and an empty property list. That record recursively contains the whole file.

Node records: the recursive tree and the 7.5 change

The body of a binary FBX file is a tree of node records. Each record describes one node and then, optionally, its children. A record is laid out like this:

NodeRecord:
  EndOffset        uint32 (or uint64 in 7.5+)  byte offset where this record ends
  NumProperties    uint32 (or uint64 in 7.5+)  count of properties in this record
  PropertyListLen  uint32 (or uint64 in 7.5+)  byte length of the property list
  NameLen          uint8                        length of the node name
  Name             NameLen bytes                node name (not null-terminated)
  Properties       PropertyListLen bytes        typed property values
  NestedRecords    zero or more child NodeRecords
  NullRecord       all-zero record that terminates the child list

Each property is typed. A property can be a single value (integer, float, double, boolean or string) or an array, and array properties may be zlib-compressed to save space. The child list is closed by a NULL record made entirely of zero bytes.

The important structural change arrived in FBX version 7.5. In files below 7.5 the three leading fields (EndOffset, NumProperties and PropertyListLen) are 32-bit, and the terminating NULL record is 13 bytes of zeroes. In 7.5 and later those three fields became 64-bit, which lets a single file exceed the old 4 GB offset limit, and the NULL record grew to 25 bytes of zeroes (8 + 8 + 8 + 1). A parser that assumes 32-bit fields will misread a 7.5 file, which is why the version number in the header has to be checked before walking the tree.

The object, property and connection graph

The node tree stores the data, but the meaning comes from how objects connect. FBX models a scene as a graph. Under the top-level records sit the definitions: geometry objects with their vertices, polygons, normals and UVs; materials and textures; deformers and skin clusters holding bone bindings and weights; animation stacks and layers containing the keyed transforms and morph targets; and cameras and lights. A separate Connections section then wires these together, stating which material belongs to which mesh, which deformer drives which geometry, and which animation curve targets which node property. Reading FBX correctly means resolving that connection graph, not just reading objects in isolation. A property can also be a custom user property, which is one of the places where tools diverge, since custom data is easy to write and easy to ignore on import.

Why imports go wrong: units and up-axis

The most common complaint about FBX is that a model imports at the wrong size or lying on its side. Both problems come from metadata that programs interpret differently. Units are the first culprit: applications disagree on the scale factor, so a model can arrive 100 times too large or 0.01 times too small, and the usual fix is an import scale of 0.01 or 100. The second is the up-axis. Some tools treat Z as up and others treat Y as up; when a Z-up scene is read as Y-up, characters and props import rotated flat, which is the classic “model is lying down” result. Smoothing groups and custom properties are further points where two importers can produce different results from the same file. None of this is corruption. It is the format leaving room for interpretation, and each importer filling that room its own way.

One security note belongs here rather than in a section of its own: an FBX file is 3D data, not a program, but parser vulnerabilities have existed historically in the FBX SDK and in third-party importers. Keep 3D software updated, and verify that a file’s real extension is .fbx and not an executable renamed to look like a model.

The closed FBX SDK and interchange alternatives

FBX is proprietary and there is no fully published specification. Most software reads and writes it by licensing Autodesk’s closed-source FBX SDK. Because the format is not open, implementations reverse-engineer or approximate the parts the SDK hides, which is the root cause of the interoperability quirks above. The Blender project’s reverse-engineered binary format notes and Autodesk’s own FBX overview are the practical references.

Several open formats overlap with FBX and are worth knowing. glTF and its binary form GLB are a modern open standard from the Khronos Group; they keep PBR materials and animation and are the usual choice for web and AR delivery. COLLADA (.dae) is an open XML format that also carries geometry, materials and animation. USD and USDZ are an emerging interchange and AR standard. For a static export that drops rig and animation, OBJ remains common, and STL reduces a model to a bare triangle mesh for 3D printing. FBX is still dominant for game-engine pipelines, but glTF and USD are the formats built to be open where FBX is not.

A footnote on the extension itself: an obscure ArcView/Esri spatial-index sidecar also uses .fbx. It is a different, minor format. The dominant meaning of the extension is the Autodesk 3D file described here.

FAQ

What changed in FBX binary version 7.5?

In version 7.5 the node record’s three leading fields (EndOffset, NumProperties, PropertyListLen) grew from 32-bit to 64-bit, and the terminating NULL record grew from 13 to 25 bytes of zeroes. This removed the old 4 GB file-offset limit. A reader must check the header version before parsing, because 7.5 files are laid out differently from earlier ones.

Why is my imported FBX tiny or lying on its side?

Both are unit and axis mismatches. If the model is far too large or too small, set an import scale of 0.01 or 100 to match the source program’s units. If it imports rotated flat, the source used a different up-axis (Z-up versus Y-up); switch the importer’s up-axis setting to match.

Binary or ASCII FBX — which should I use?

Use binary for normal work: it is smaller and faster, and it is what engines and tools expect. Use ASCII only when you need to read or diff the file by hand to debug an export. The two carry the same data.

Why do different apps import the same FBX differently?

Because the format is proprietary and not fully documented, importers interpret the ambiguous parts — units, smoothing, custom properties, some material settings — in their own way. The FBX SDK hides details, so two programs can read one valid file and disagree on the result.

References