Binary FBX header and node records

A binary FBX file is a 27-byte header, a list of node records that nest inside each other, and a footer. Autodesk publishes no specification: this page follows the notes the Blender developers published in 2013 and the comments added to them since, and Blender’s own FBX writer. All numbers are little-endian.

File header

Offset	Size	Type	Name	Description
0	21	char[21]	magic	`Kaydara FBX Binary`, two spaces and a zero byte
21	2	bytes	unknown	`1A 00` in every file seen; their meaning is not known
23	4	u32	version	the FBX version times 1000, such as 7400 for 7.4

00000000  4B 61 79 64 61 72 61 20 46 42 58 20 42 69 6E 61
00000010  72 79 20 20 00 1A 00 E8 1C 00 00

The header of a version 7400 file: the magic, 1A 00, then 7400 (0x1CE8)

Versions

Versions met in files include 6100 (FBX 6.1) and 7100 to 7500 and 7700 (FBX 7.1 to 7.7). The one change to the binary layout is at 7500: from there the first three fields of every node record are 64-bit instead of 32-bit, so the null record grows from 13 to 25 bytes. Autodesk’s release notes for 7.5 say the change lets files grow past 2 GB and that FBX 2015 and older cannot import it. Everything else, including the property types, is the same in all versions.

Node records

Each node has a name, a list of typed values called properties, and an optional list of child nodes.

Field	Size before 7500	Size from 7500	Description
`EndOffset`	4 (u32)	8 (u64)	the offset from the start of the file to the byte after this record, children included
`NumProperties`	4 (u32)	8 (u64)	the number of properties
`PropertyListLen`	4 (u32)	8 (u64)	the length of the property list in bytes
`NameLen`	1 (u8)	1 (u8)	the length of the name
`Name`	`NameLen`	`NameLen`	the node name, such as `Objects` or `Vertices`, with no terminating zero
properties	`PropertyListLen`	`PropertyListLen`	the properties back to back, without padding; see Property types
children	to `EndOffset`	to `EndOffset`	child node records, present when bytes remain before `EndOffset`, then a null record

EndOffset is absolute, so a reader can skip a node it does not need by seeking to it. Readers are advised to trust it rather than search for the null record.

Null records

A list of child nodes ends with a null record: a node header with every field zero, 13 zero bytes before version 7500 and 25 from 7500. The top-level list ends with one too, just before the footer. Blender’s writer also puts one after a node that has neither properties nor children unless it is the last in its list, and always after AnimationStack and AnimationLayer nodes, which the FBX SDK appears to need. Whether a null record is required in other places is not known; a node without children usually has none.

The Blender developers’ first notes describe an unnamed top-level node holding the whole tree. Later readers found that files have no such node: the first record after the header is a real node, usually FBXHeaderExtension.

Footer

After the top-level null record comes a footer. Its meaning is not public; this is the layout Blender writes, which the FBX SDK accepts.

Size	Contents
16	a footer id; Blender writes `FA BC AB 09 D0 C8 D4 66 B1 76 FB 83 1C F7 26 7E`
4	zero
1 to 16	zero padding to the next multiple of 16 bytes from the start of the file, a full 16 when already aligned
4	the version again, u32
120	zero
16	`F8 5A 8C 6A DE F5 D9 7E EC E9 0C E3 75 8F 29 0B`, the same in every file

Blender’s writer notes that the FBX SDK checks values derived from the file’s timestamp. Not knowing the rule, Blender writes a fixed CreationTime (1970-01-01 10:00:00:000), a fixed FileId and the fixed footer id above, a combination that Autodesk’s software accepts. How the SDK computes them is not known.

Worked example

A node FBXHeaderVersion with one 32-bit integer property, 1003, in a version 7400 file, starting at offset 58 (0x3A) inside FBXHeaderExtension:

0000003A  5C 00 00 00 01 00 00 00 05 00 00 00 10 46 42 58
0000004A  48 65 61 64 65 72 56 65 72 73 69 6F 6E 49 EB 03
0000005A  00 00

EndOffset 92 (0x5C), one property, a property list of 5 bytes, a 16-character name, then the property: type I (0x49) and the value 1003 (0x3EB)

The record is 34 bytes, so it ends at 58 + 34 = 92. In a version 7500 file the three counts would take 8 bytes each and the record would be 46 bytes.