STLBenchFree online OBJ to glTF converter
OBJ to glTF, without inventing the PBR values
Drop an .obj and download a .gltf, rewritten inside the page with no transmission of any kind. The output is JSON with its buffers embedded — one file, readable, editable, which is the reason to pick this form over the binary one. Geometry, UVs and group names cross intact and the coordinates are multiplied by 0.001 for glTF's metres. What does not cross is the material model: a .mtl describes Phong shading and glTF describes metallic-roughness, and no arithmetic connects them, so the base colour is carried and nothing is fabricated around it.
- 100% free
- No signup
- Readable JSON
- Metres out
- Nothing uploaded
Drag a file anywhere on this page to open it. F fits the view, W switches shading, G the grid, R spins it.
How to convert OBJ to glTF
Three steps, and one expectation to set about materials.
Drop the .obj
Geometry, groups and UV coordinates are read out of the text. What you get back is a .gltf with its vertex buffers embedded, so the single file works on its own instead of pointing at a .bin.
Expect metres, and expect no PBR values
The coordinates are multiplied by 0.001 because glTF counts in metres. The material is written as a plain base colour with no metalness or roughness worth trusting, since the source had no such concept to convert from.
Download the .gltf, then open it
It is JSON, and being able to read it is the reason to choose this form over GLB. The node names, the accessor counts, the material block — all of it is inspectable in a text editor, which is exactly what you want while a model is still being worked on.
Technical specifications
| Reads | .obj — text, with named groups and UV coordinates |
|---|---|
| Writes | .gltf — JSON with buffers embedded, self-contained |
| Unit | Millimetres in, metres out — factor ×0.001, printed in the panel |
| Kept | Geometry, UV coordinates, group names, base colour |
| Not converted | Phong specular and shininess — glTF has no equivalent to translate them into |
| Sibling files | The .mtl and its textures, read when dropped alongside the .obj |
| File size | No fixed limit — past 100 MB you are told what it will cost this tab, then it opens |
Frequently asked questions
Why does the material look flat?
Because the two formats describe surfaces with incompatible physics. A .mtl stores Phong parameters — an ambient colour, a diffuse colour, a specular colour and a shininess exponent — which are a 1975 approximation of how light bounces. glTF stores metallic-roughness, which is a physically-based model: is this metal or not, and how rough is it. There is no formula that turns one into the other, only a guess. Rather than dress a guess up as data, the output carries the base colour and leaves the PBR values at sensible defaults for you to set deliberately.
Should I use .gltf or .glb?
Use .gltf while you are working and .glb when you ship. This page writes the JSON form because it is readable and editable, which matters when you are checking that a node ended up where you expected. For a web page, the binary form is smaller and one file — and converting between them afterwards costs nothing at all.
Do my UVs survive?
Yes, and they are the most valuable thing that does. A UV layout is real work — somebody unwrapped that mesh — and it converts intact, so a texture lands where it was meant to. The image itself comes along too if you drop it with the .obj and its .mtl; on its own, the .obj carries only the pointer.
Why is the file bigger than my .obj?
Because embedding binary data in JSON requires base64, which costs a third on top of the raw bytes, and because vertex data is stored as full-precision floats rather than as trimmed decimal text. The binary GLB form is smaller than both. If size is what you care about, this is the wrong form of the format to be writing.
Are the group names kept?
Yes, as node names in the scene tree. Nesting is not: a parent's transform ends up multiplied into its children's vertices, which leaves the parts at the right coordinates as siblings rather than in a hierarchy.
Is my file uploaded?
No. The text is parsed and the JSON written in this tab, so nothing crosses the network.
About two ideas of what a surface is
The gap between these formats is not really about syntax. It is that they were written on opposite sides of a change in how computer graphics thinks about light. OBJ's companion .mtl encodes the Phong model: a diffuse colour, a specular colour, a shininess number, all of them dials an artist turned until the render looked right on that renderer. Nothing in it corresponds to a physical property of a material.
glTF encodes metallic-roughness, where the parameters claim to mean something — base colour is albedo, metalness says whether the surface conducts, roughness says how scattered the reflection is — and the point of the claim is that a model lit correctly in one engine is lit correctly in the next. That portability is exactly why the web standardised on it.
So a converter facing a .mtl has two options: guess, or say so. Guessing produces files that look plausible and are wrong in ways nobody can trace back. This page carries the base colour, leaves metalness and roughness at neutral defaults, and lets you set them where the information actually exists — in your hands. If you would rather ship the binary form, GLB packs the same scene smaller, and the return trip drops the PBR data entirely, which is the same problem seen from the other end.
Where the conversion happens
Every number on this page is worked out by JavaScript running in the tab you are reading it in. The model you open is read straight off your own disk — it is never uploaded, logged or kept, which is also why these tools carry on working after you disconnect from the network.
Worth adding here, since the output is text you can read yourself: it is worth saying that nobody else read it. The .obj went in at one end of this page and the .gltf came out of the other, with no server in between to keep a copy.