Convert an .obj into a GLB that engines and browsers read. Geometry and UVs travel; OBJ has nothing else to carry.
OBJ is a text format from 1992 that stores vertex positions, texture coordinates, normals and the faces connecting them. That list is complete — there is nothing else in the file. So the conversion is lossless in the only sense that matters: everything OBJ can express arrives in the GLB.
What arrives with it is nothing, because OBJ has no skeleton, no animation, no scene hierarchy, no lights and no cameras. If you are looking for a rig in the output, the file you started with did not have one. This is worth stating plainly because "my animation disappeared" is the most common thing people report about OBJ conversion, and the animation was never in the .obj.
An OBJ does not contain its materials. It contains a line pointing at a sibling .mtl file, which in turn points at image files by relative path — map_Kd textures/diffuse.png and so on. The model is a set of three or more files that only work when they sit together in the right folder.
A browser tab cannot follow those paths. Dropping a single .obj onto this page gives the converter no way to reach the .mtl, and no way to reach the images even if it could read the .mtl. So the model arrives with a default material, and this page says so rather than pretending otherwise.
If the materials matter, the fix is upstream: re-export from your source tool as GLB or FBX with media embedded, both of which put the textures inside the file. That is the whole reason glTF exists as a container format.
The format records numbers and declines to say what they mean. One exporter writes metres, another centimetres, a third whatever the modelling scene happened to use. glTF, by contrast, has a convention — metres, Y-up — that every engine reading it assumes.
There is no heuristic that reliably bridges that, so this page does not invent one. It reports the largest dimension of the model after conversion and warns when the number is far from what a glTF pipeline expects. Scaling is left to you or to your engine's import settings, where you know what the model is supposed to be.
What it does fix is position. OBJ exports routinely carry the world-space offset of whatever scene they came from, so a converted model can sit kilometres from the origin and read as a failed import — the file loaded, the camera is just nowhere near it. Recentring is on by default because that offset is never information.
Because nothing on the web reads OBJ. There is no browser-native support, no streaming, no compression story, and no single-file form — you are shipping a folder. glTF was designed for exactly this gap and is what three.js, <model-viewer>, Babylon and every web viewer expect.
It matters in engines too. Godot imports a GLB as a scene with no configuration; Unity reads glTF through glTFast or UnityGLTF; Unreal has it built in. An OBJ imports as raw geometry in all of them and you rebuild the material by hand at the other end.
The one place OBJ still earns its keep is as a lowest-common-denominator geometry exchange between desktop modelling tools, and for 3D printing where colour is irrelevant. Convert at the boundary — keep OBJ between DCC tools, ship glTF to anything that renders.
A converted OBJ is usually a static prop, which makes it the easiest kind of asset to finish. If it is dense — scans and CAD exports often are — reduce the polygon count; the quadric decimator carries UVs through, so a textured model stays textured. If it needs a clean UV layout before you paint or bake on it, quad remeshing rebuilds the topology and re-unwraps it in one pass.
And if you are unsure what state the file is in — OBJ from a scanner or a CAD export can carry non-manifold geometry, inverted faces and holes — the model doctor reports on all of it in a few seconds.
Drop the file above and download the result — the parse and the glTF write both run in your browser tab, so there is nothing to install and nothing to upload. The caveat is materials: an OBJ references them through a sibling .mtl and a browser cannot follow that path, so the model arrives with a default material. If you need the materials, Blender (or any DCC) is still the answer, because the fix is to re-export with the textures embedded.
Because the .obj never contained them. It points at a .mtl file, which points at image files by relative path, and a browser tab cannot reach either. The model is a folder of files pretending to be one file. Re-export from your source tool as GLB or FBX with media embedded and the textures travel inside the file.
No. The format stores vertex positions, texture coordinates, normals and faces — there is no skeleton, no animation track, no scene hierarchy. If your model was animated before it became an .obj, the animation was lost at that export, not at this conversion.
Whatever it was, because OBJ does not record units. One exporter writes metres, another centimetres. glTF assumes metres, so a model authored in centimetres will land a hundred times too large in an engine. This page reports the largest dimension after converting and warns when it looks wrong, but does not guess at a correction — set the scale in your engine's import settings, where you know what the object is supposed to be.
Usually the world offset. OBJ exports often carry the coordinates of whatever scene they came from, so the geometry can sit far from the origin — the file loaded fine, your camera is just nowhere near it. Recentring is on by default here for exactly that reason. The other possibility is scale: a model a thousand units across is off-screen at any sane camera distance.
Not here. The pipeline runs toward glTF because that is what renders on the web and imports cleanly into engines, and going back would discard everything OBJ cannot hold.
For anything that renders — a browser, a game engine, a viewer — GLB, and it is not close: one self-contained file, PBR materials defined identically across renderers, rigs and animation, and native support everywhere. OBJ is still reasonable as plain geometry exchange between modelling tools and for monochrome 3D printing. Convert at the boundary.
No. The OBJ is parsed and the GLB written in your browser tab. Nothing is sent anywhere, which is also why it works offline once the page has loaded.
Up to 100 MB. OBJ is text, so it is a verbose way to store geometry — a mesh that would be a few megabytes as a GLB can be five times that as an .obj, and the parsed representation in memory is larger again. If your file is bigger, it is usually a scan or a CAD tessellation that wants decimating first anyway.