Browser-local converter
GLB to OBJ converter
Convert a GLB or glTF scene into a Wavefront OBJ on your own machine. This is one of the few conversions here that loses almost nothing: OBJ can carry the normals, uv coordinates and material colours that GLB holds, so they are written rather than dropped.
Drop your GLB files here
STL, OBJ, PLY, GLB, glTF, 3MF, SVG and DXF. Nothing is uploaded: files are read and converted inside this tab. Checking what this device can handle...
Queue
No files yet. Drop models above, or use the file picker.
Output
Units
Size and placement
Repair and cleanup
These can change the shape, so they need a before-and-after review before export.
Inspection
Add a model to see its dimensions, mesh health and estimated volume.
What this GLB to OBJ conversion does and does not do
- Material colours are written to a companion .mtl file, one material per glTF material, carrying diffuse colour and opacity. The .obj and the .mtl are both produced and must be kept together.
- Texture images are never written. A glTF embeds its images inside the binary chunk, and extracting and re-encoding them is deliberately out of scope, so no map_Kd line is emitted for a material whose image only existed inside the GLB.
- The scene graph is flattened. Node transforms are baked into the vertices, so the shape is right, but glTF nodes become flat OBJ objects with no hierarchy or parenting.
- glTF is defined in metres and OBJ records no unit at all, so the numbers are written in the unit you select in the workspace. A model left in metres becomes single-digit numbers that most tools will read as millimetres.
- Animations, skins, morph targets, cameras and lights are ignored, because OBJ is a static surface format with nowhere to put them.
- Draco and meshopt compressed geometry is refused with a clear message rather than partly read. Re-export without mesh compression.
Troubleshooting
The model has no colour when I open the OBJ
Keep the .mtl next to the .obj and load the .obj, not the .mtl. OBJ stores material data in the sidecar and references it by filename, so moving or renaming one of the two files breaks the link.
The textures are missing even though the .mtl is there
That is expected. The image data lived inside the GLB and is never extracted or re-encoded here. The workspace lists the textures the source referenced so you know exactly what was not written.
The OBJ imports at a tiny size
This is the metre-versus-millimetre problem. glTF measures in metres, so a 0.2 m model exports as the number 0.2 and a slicer reads it as 0.2 mm. Set the unit to millimetres in the workspace before exporting.
The file is much larger than the GLB
OBJ is plain text and GLB is packed binary, so several times the size is normal. Nothing has been added to the model.
Questions
Does this keep the materials?
Colours and opacity, yes, as a standard .mtl sidecar. Texture images, no: they are embedded in the GLB and are never extracted. This is the honest half of the answer that most converters leave out.
Will it open in Blender, Maya and Cinema 4D?
Yes. The OBJ is written to the standard with global 1-based indices, and every export is validated by re-parsing it and comparing triangle counts, mesh counts and bounding box against the source before you download.
What is the difference between GLB and glTF here?
GLB is the single-file binary form and works on its own. A .gltf is JSON that usually references a separate .bin, which you need to add to the queue alongside it.