執筆：Huy Nguyen · ·
GLB is what you get from Sketchfab, from a Blender glTF export, from a photogrammetry service or from anything built for the web. FBX is what Unity, Unreal, Maya and 3ds Max ask for. Converting between them is one of the most common jobs in game and animation work, and the question is almost never whether the triangles arrive. It is whether the rig, the textures and the animation arrive with them.
Those are fair things to worry about, because a lot of converters quietly drop them. A GLB can carry a skeleton, per-vertex skin weights, PBR materials with textures packed inside the single file, and animation clips. FBX can carry all of that too, so a good conversion should lose nothing of substance.
Rather than assert that, we built three GLB files today, including one with a real two-bone skinned rig and one with a PNG texture embedded in the file, converted them through the same converter this page uses, and then re-opened every result in Blender 5.1 and read the raw FBX bytes. The findings below are what we measured.
What the test conversions kept and lost
Three inputs. A plain scene of two named objects with one solid colour each and a 40-frame rotation on one of them. The same kind of scene but with a 64 by 64 PNG texture embedded inside the GLB and mapped through a UV layout. And a skinned rig: an armature of two joints, a mesh bound to it with per-vertex weights, and a 30-frame bone rotation.
| What went in | What came out | Verdict |
|---|---|---|
| Two named objects per scene | Two mesh objects, same names | Kept. Nothing was welded together and no temporary names appeared |
| 972 and 540 triangles | 972 and 540 triangles | Kept exactly, vertex for vertex |
| Named materials with base colours | The same names and the same colours to two decimals | Kept |
| A PNG texture embedded in the GLB | The same image embedded inside the FBX | Kept. No separate image file to carry around |
| UV layouts | UV layouts | Kept |
| A 40-frame rotation animation | One clip, frames 1 to 40 | Kept, though rewritten as baked transform curves |
| An armature of two joints | An armature with the same two bones | Kept |
| Per-vertex skin weights | The same two weight groups, bound to the rig | Kept |
| A 30-frame bone animation | One clip, frames 1 to 30, with real bone curves | Kept |
| Coordinates in metres | Identical numbers, same up axis | Kept. Nothing was scaled or rotated |
The rig survives, and this is the part worth knowing
This is the question most people actually have, so we built a file specifically to answer it. The input was a small skinned arm: an armature with joints named Lower and Upper, a mesh bound to both with per-vertex weights, and a 30-frame rotation on the upper joint.
After conversion the FBX still contains an armature with bones Lower and Upper, the mesh still has its two weight groups named after those bones, and it is still bound to the skeleton. Reading the FBX directly, the skinning data is where it should be: a skin deformer with one cluster per joint and a stored bind pose. The animation came back as a single clip covering frames 1 to 30, with curves on the Upper bone rather than merely on the object.
So a rigged GLB character converted here should arrive in your engine as a rigged character. The caveat worth stating plainly: our rig has two bones and one clip. We have not tested a full humanoid skeleton, several clips in one file, or blend shapes, so treat those as untested rather than confirmed.
Textures travel inside the FBX
A GLB keeps its images inside the single file, which is the whole point of the format. FBX can do the same, and in our test it did: the PNG bytes are embedded in the FBX itself, alongside a reference in the standard embedded-media form that FBX uses. Re-importing in Blender recovered the 64 by 64 image and the UV map with it.
This matters because the usual texture complaint after a conversion is a model that arrives plain grey with a missing-file error. That did not happen here, and there is no sidecar image you need to keep next to the FBX.
One honest detail we measured. On the textured material, the base colour value arrives as plain white with the texture providing the colour, where the original GLB had no base colour value at all and relied purely on the texture. The visible result is the same, but if you were expecting a colour tint to also be sitting in that slot, it is not.
Animation survives, but it is rewritten as baked curves
Both animated scenes came back with their clip intact and the same frame range: 1 to 40 for the object rotations, 1 to 30 for the bone animation. Nothing was truncated and no clip went missing.
How it is stored does change. A GLB writes a rotation as a quaternion and only writes the channels that actually move. The FBX we got back has position, rotation and scale curves on every animated node, with the rotation expressed in Euler angles, and the moving channel carrying one key per frame.
For playback that makes no difference, which is why FBX does it: baked transform channels are unambiguous in any engine. It matters if you intended to edit the curves afterwards, because you will find thirty keys where you authored two, and Euler angles where you authored a quaternion. If curve editing is the goal, keep the GLB, or better the original project file, as your source of truth.
Up axis and scale need no fixing here
This is the one place GLB to FBX is easier than most conversions. Both formats use Y as the up axis, so there is no rotation to undo. The FBX we got back declares exactly that: up axis Y, front axis Z, and a unit scale factor of 1, written as a binary FBX of version 7400.
The coordinates themselves are untouched. Our 0.05 metre cube is still 0.05 in the FBX, the 0.03 metre ball is still 0.03, and the objects sit at the same heights they did in the GLB. Nothing was multiplied.
What that means in an engine depends on the engine, not on the file. FBX counts its units in centimetres by convention while glTF counts in metres, so a 0.05 that meant five centimetres in the GLB may be read as half a millimetre by an importer that assumes centimetres. If your model arrives a hundred times too small or too large, the fix is the import scale setting in Unity, Unreal or Maya, not another conversion. We tested only in Blender, which read it back at the original size.
What is genuinely not in an FBX
- Draco compression. A GLB can be Draco-compressed to a fraction of its size, and FBX has no equivalent, so expect the FBX to be larger in that case. We did not test a Draco file.
- The single-file guarantee, in principle. FBX can reference external textures instead of embedding them. Ours embedded, but an FBX you receive from elsewhere may not, so check before you move it between machines.
- Web readiness. If your destination is a browser or a web viewer, FBX is the wrong direction entirely. Keep the GLB.
- Anything the GLB did not have. If your GLB is an unrigged static mesh, no conversion adds a skeleton to it.
File size moves in both directions
There is no simple rule here, and our three tests went different ways. The plain two-object scene shrank from 73,656 to 55,980 bytes. The textured scene grew slightly, from 43,548 to 46,092 bytes. The rig grew a great deal: 9,452 bytes of GLB became 40,076 bytes of FBX, more than four times larger.
The pattern behind it is that FBX is verbose about skeletons and about baked animation curves, and reasonably efficient about plain geometry. A heavily rigged and animated character will therefore grow the most, which is worth remembering if you are close to an upload limit in the other direction.
Our largest test file was under 75 KB, so these are proportions rather than a guide to how a 200 MB character will behave.
Doing the same job on your own machine
- Blender is the standard route and it is free: File, Import, glTF 2.0, then File, Export, FBX. In the FBX export panel, Path Mode set to Copy with the Embed Textures button enabled is what puts the images inside the FBX rather than beside it.
- If the file is a rigged character, limit the FBX export to Armature and Mesh in the Object Types list. Exporting cameras, lights and empties as well is the usual cause of stray nodes appearing in an engine.
- Unity and Unreal both import GLB directly in recent versions, so if your destination is one of those, check whether you need an FBX at all before converting.
- The Autodesk FBX Converter is a free standalone tool, but it is old and does not read glTF or GLB, so it cannot help with this particular direction.
Limits here, and what happens to your file
- Free: up to 30 MB per file, 10 conversions per hour, 2 running at the same time, no account needed.
- Pro: up to 1 GB per file, 50 conversions per hour, 5 at the same time. Rigged character files reach 30 MB more easily than static meshes do.
- Uploaded files and their converted results are deleted from our servers within 1 hour of upload.
- From a GLB this site converts to FBX, OBJ, STL, GLTF and USDZ. Of those, FBX and USDZ are the ones that can carry the animation; OBJ and STL cannot.
Tested on 29 October 2026 with three GLB files built in Blender 5.1: a two-object scene with coloured materials and a 40-frame rotation (73,656 bytes), a two-object scene whose material carries a 64 by 64 PNG texture embedded in the GLB plus the same animation (43,548 bytes), and a skinned rig with an armature of two joints, per-vertex skin weights and a 30-frame bone animation (9,452 bytes). All three were converted here to FBX, re-imported in Blender 5.1 to count objects, vertices, materials, textures, bones, vertex groups and animation curves, and the FBX files were also read directly to check the declared up axis and unit scale.