OBJ to GLB converter — folder in, one file out

VTubeMe's OBJ to GLB converter packs a zipped .obj, its .mtl and the images they name into a single .glb that web viewers and engines load directly. Free, five conversions a day, nothing to install.

Free · 5 conversions a day per accountNeed a VRM avatar instead? →

Upload the folder, not the file

The converter takes the .obj, the .mtl beside it and the images they name, and writes a single .glb with all of it packed inside — the format three.js, model-viewer, Babylon.js, Godot and every modern engine load without a loose folder to babysit.

A bare .obj is accepted and converts fine — it just comes out grey, because the colours were never in it. The .obj names materials, the .mtl beside it describes them, and the images sit beside the .mtl. Zip the whole folder and all three are read together.

The difference is measurable on one model: converted alone it gave a 0.83 MB GLB with its eight material names and no textures; converted as a zip with its .mtl and images it gave 7.21 MB with five images inside and six of the eight materials textured. Same geometry, same 27,708 triangles, all the colour in the second one.

On a second textured game model, five materials and four PNG files went in and the .glb came out with all five materials and all four images packed inside it, at the same 3,116 triangles.

Why the vertex count jumps

The same model reported 1,734 vertices as an OBJ and 3,503 as a GLB. Nothing was added. OBJ lets several faces share one vertex while giving each face its own normal and UV; glTF requires one vertex per unique combination of the three, so shared vertices at hard edges and UV seams are split into copies. The triangle count — 3,116 on both sides — is the number that means the same thing in both formats.

What this conversion cannot do

Measured on real files, not assumed. Everything below is a property of the formats or of the pipeline, and knowing it beforehand is cheaper than discovering it in your 3D tool.

A GLB cannot invent a rig

GLB can hold a skeleton; your OBJ has none, so the result has none either. Nothing is lost in this direction — there was nothing there to lose — but if you are here hoping to end up with an animatable character, rigging is a separate step that has to happen before any of this. Mixamo's auto-rigger is the free route: upload the mesh, download the result as FBX Binary.

Materials are approximated

The .mtl material model is from 1992: a diffuse colour, a specular colour, a shininess number, and optionally a texture for each. glTF is metallic-roughness PBR. The mapping between them is an approximation everyone makes the same way — your colours and diffuse maps come across, and a precise look from a renderer that read the .mtl its own way will not be reproduced byte for byte.

Animation does not travel

The skeleton is written, the motion curves are not. Reading an FBX's animation costs about 1.5 GB of memory on a long clip, which is more than the converter container has, so the importer is asked to skip it and the exporter writes none. A file that arrives with a walk cycle leaves with the same rig in its bind pose. If what you have is the motion rather than the model, the FBX to VRMA converter is the tool that keeps it.

Five conversions a day, per account

This pair is free and takes no credits, but one account gets five conversions per rolling 24 hours across all six pairs together — the converter is one machine and this is what keeps it answering. Each slot frees itself 24 hours after it was used; nothing expires at midnight. Conversions that fail are not counted.

Frequently asked questions

Do I upload the .obj alone or the whole folder?

The whole folder, zipped, whenever the model is textured — the .obj carries only geometry, the .mtl beside it carries the materials, and the images sit beside that. A lone .obj converts, but the .glb will be grey. Zipping is the only way the three arrive together.

Are the textures inside the resulting .glb?

Yes — that is the main reason to convert. On the model we measured, four separate PNG files ended up packed inside a single 214 KB .glb. There is no folder to keep together afterwards and no path to re-link.

Can I use the GLB on a website?

That is what the format is for. Google's <model-viewer>, three.js and Babylon.js all load a .glb directly, and one self-contained file is far easier to host than an OBJ folder. Drop the result into the free GLB viewer first to confirm it looks right. Open the GLB viewer →

Why does my viewer show more vertices than my modelling tool did?

Because glTF counts differently: it stores one vertex per unique position-normal-UV combination, so hard edges and UV seams split shared vertices. Our test model went from 1,734 to 3,503 with the triangle count unchanged at 3,116. The mesh is the same mesh.

Can this become a VTuber avatar?

Not on its own. An avatar needs a humanoid skeleton and an OBJ has none, so the route is: rig the mesh first — Mixamo's free auto-rigger is the usual choice — and convert that rigged FBX to VRM. Auto-rigging gives you a body that moves; it does not give you a face that blinks. FBX to VRM converter →

The other format pairs

All six are free, all six run the same pipeline, and all six say what they drop.

Only want to look at the file? GLB viewer, FBX viewer and OBJ viewer all run on your own device — nothing is uploaded.

Is your model going into VTubing?

Planning to use this model as an avatar? A GLB is the right container but not the right format for VTubing apps — and an unrigged mesh is not an avatar at all. Rig it first, then convert the rigged file to VRM, which is what VSeeFace, Warudo and VNyan actually open.

Open the VRM converter