Convert an FBX — Mixamo, Blender, an AI generator — into a GLB, with the centimetre scale fixed on the way through.
FBX and GLB describe the same things — meshes, materials, a skeleton, animation tracks — in different dialects, so this is a re-encoding rather than a reduction. Geometry, UVs, materials, bones, skin weights and every animation clip in the file come across. A rigged character arrives rigged; a file with twenty clips arrives with twenty.
Textures come across when they are embedded in the FBX. This is the one place the format bites: FBX also lets textures live beside the file as loose images referenced by path, and a single .fbx dropped into a browser tab has no way to reach them. If your model lands untextured, that is why — re-export from the source tool with media embedded. Mixamo’s “With Skin” downloads carry their texture inside the file, so they are fine.
Mixamo hands you a character roughly 180 units tall, because it thinks in centimetres. GLB convention is metres, and every engine that reads GLB assumes so. Drop the raw conversion into three.js, Godot or Unity next to anything authored properly and your character is a hundred times the size of the world — the single most common reason a Mixamo model “does not work” after conversion.
So the scale fix is on by default: when the model arrives over 10 units, it is divided by 100. That is a true centimetre-to-metre conversion, not a fit-to-a-box, and the distinction matters the moment you convert a second file. Dividing everything by 100 keeps a child shorter than an adult. Normalising each model to the same height does not — it quietly destroys the relative scale between your own assets, and you find out when they stand next to each other.
Turn it off if your FBX is already in metres, or if the model is genuinely large — a building at 50 units reads as centimetres to any heuristic, including this one.
This page turns one file into one file. It does not put Mixamo’s animation onto your character — that needs two skeletons and a bone mapping between them, which is a different operation with different failure modes. It lives in the editor: see retarget Mixamo animations to any character.
The rule of thumb: if you downloaded a character from Mixamo and want it in your engine, this page is the whole job. If you downloaded a clip from Mixamo and want it on a model you already have, you want the retargeter.
They are the same format. glTF is the specification; .gltf is its JSON form and .glb is the binary container that wraps that JSON together with the geometry buffer and the images in one file. Anything that reads one reads the other, so the choice is purely about how many files you want to keep track of.
A .gltf export is typically three or more artefacts: the JSON, a .bin beside it, and a folder of textures — all referenced by relative path. Move one, rename one, or upload the set out of order, and the model loads with pieces missing. This is the exact failure that leaves FBX users with untextured models, reproduced in a new format.
A GLB is one file that cannot come apart. For anything you are going to hand to an engine, attach to a message, or serve over HTTP, that property is worth more than the marginal convenience of editing the JSON by hand. So this page writes GLB, and if you specifically need the split form, any glTF tool will unpack a GLB into it.
three.js — GLTFLoader reads GLB directly; the animation clips arrive on gltf.animations and you drive them with an AnimationMixer bound to gltf.scene. This is the combination that motivates most conversions on this page, and the scale fix is what makes the character arrive at human size instead of filling the world.
Godot — drag the .glb into the project and it imports as a scene with an AnimationPlayer already wired. No plugin, no import settings to fight.
Unity — glTF is not built in; add glTFast or UnityGLTF from the package manager. Unity does read FBX natively, so if Unity is your only target the conversion may be unnecessary — its FBX importer has a scale factor field that handles the centimetre problem for you.
Unreal — glTF import is built in and reads GLB. Unreal is centimetre-native, so a correctly scaled GLB in metres imports at 1/100 of the size you expect; set the import scale to 100.
Because Mixamo exports in centimetres and GLB is read as metres. That is exactly what the scale fix on this page is for — leave it on and the character lands at human size.
Yes. Every clip in the FBX is written into the GLB with its timing intact, and the skeleton and skin weights come with it. A Mixamo download animates in a GLB viewer immediately.
Your FBX almost certainly references its textures as separate files sitting next to it, rather than embedding them — a browser tab cannot follow those paths. Re-export with media embedded. From Mixamo, download “With Skin” and the texture travels inside the file.
No. GLB is what engines, viewers and browsers read, and it is the direction this pipeline runs. FBX export is not supported.
Only FBX 7.0+ (binary or ASCII) is readable — the 6.x files some older tools and asset packs still ship are not. Round-tripping the file through Blender re-exports it as a current FBX, which parses here.
No. FBX parsing and GLB writing both run in your browser tab. It is the same story as every tool here — the file never leaves your machine.
Download from Mixamo as FBX with skin, convert it here with the scale fix on, and load the GLB with three.js GLTFLoader. The clips come through on gltf.animations; feed them to an AnimationMixer bound to gltf.scene and the character animates. The scale fix is the step people skip and then spend an afternoon on — Mixamo exports in centimetres, three.js reads glTF as metres, and without the divide-by-100 your character is 180 units tall in a world built at human scale.
For anything a browser loads, yes, and not by a small margin. GLB is a single self-contained file, defines PBR materials the same way every renderer implements them, and is what glTF loaders are built for. FBX is a proprietary format with dialects that vary by exporter, textures that often live outside the file, and no browser-native support — reading it at all means shipping a parser to the client. Keep FBX as an interchange format between desktop tools and convert at the boundary.
Up to 200 MB. That is a memory ceiling rather than an arbitrary policy: parsing happens in your tab, and the intermediate representation of a large scene is several times the file on disk. If yours is larger, it is usually a scene rather than an asset — split it in the source tool and convert the pieces, which is what you want in an engine anyway.