Convert OBJ to GLB

No browser reads OBJ, and none reads GLB natively either — a .glb navigated to directly downloads rather than renders. What differs is the library ecosystem. three.js, Babylon.js and the model-viewer web component all take a GLB as their primary input and load it in one fetch, while OBJ support is a side loader that also needs the MTL and every texture as separate requests.

So the practical question is not which format the browser understands but which one the runtime you are about to include expects. For anything published after 2018 that answer is GLB, and for a product page where the model is the content, collapsing four or five requests into one is a measurable difference on a phone.

An OBJ file has no materials in it. It has an mtllib line naming a .mtl beside it and usemtl lines switching between the entries in that file, and the .mtl holds the diffuse colour, the specular values and the paths to the texture images. This converter reads v, o, g and f lines and ignores the rest.

The consequence is unambiguous and worth planning around: your GLB contains geometry and group names, and your viewer draws it in whatever default material it has. If the model was going to be shown with its textures, the route is Blender — import the OBJ with its MTL, then export glTF Binary, which packs the images into the GLB. This page is for the case where the shape is the deliverable.

A glTF 2.0 binary: twelve-byte header, a JSON chunk padded with spaces to a four-byte boundary, then a binary chunk padded with zeroes. Inside the JSON, one mesh per OBJ group, one node per mesh, one scene listing them all, an asset version of 2.0, and per mesh a float32 VEC3 position accessor and a uint32 SCALAR index accessor.

Every position accessor carries min and max. That is a specification requirement and it is also the practical difference between a model that appears when you load it and one that does not — model-viewer and three.js both derive the initial camera distance from those bounds, and files written without them are a common cause of an apparently empty scene.

The reader starts a new group at every o or g line and the writer emits one glTF mesh per group, each in its own node with its own primitive. An OBJ exported from CAD with a group per face patch can carry hundreds of groups, and the GLB will faithfully contain hundreds of meshes.

On a page that is a real cost. Each primitive is a separate draw call and a separate GPU buffer binding, and a few hundred of them on a mid-range phone is where the frame rate goes. Merging objects in Blender before exporting the OBJ, or stripping the g lines with a text editor if the groups carry no meaning, is a two-minute fix worth more than most of what happens after.

No NORMAL attribute is written. The glTF specification is explicit about what a viewer must then do: compute flat face normals. So a sphere that looked smooth in your modelling software renders in the browser with every triangle visible as a distinct facet, which reads as a deliberate low-poly style and usually is not.

There are two clean fixes. In three.js, call computeVertexNormals on the loaded geometry, which averages the face normals per vertex and needs the mesh to be properly welded — which it is, since positions are merged at six decimal places during conversion. Or do the normal pass upstream in Blender and export glTF from there, which also brings the materials along.

glTF fixes both. It is right-handed, Y-up, and its linear unit is the metre. OBJ fixes neither: it is a list of numbers with no header, no unit and no axis convention, and every application that writes one has its own habit.

No conversion is applied here, so a Z-up OBJ produces a GLB whose model lies on its back and a centimetre-authored OBJ produces one two hundred metres tall. Both are trivially fixable once you know which you have — a minus 90 degree rotation about X, and a uniform scale — and both are invisible until you load the file. Checking the bounding box against a dimension you know is the fastest diagnosis.

Faces with more than three corners are fan-triangulated from the first corner, which is correct for the convex quads and n-gons these files normally contain and can produce overlapping triangles on a concave face. Negative face indices, which count backwards from the most recent vertex, are resolved as the file is read rather than afterwards, because their meaning depends on the position in the file.

Positions are then welded: matched at six decimal places, so a coordinate appearing in twenty triangles is stored once and referenced twenty times. That both shrinks the buffer and gives the browser a mesh whose adjacency is real, which is what makes computeVertexNormals produce smooth shading instead of the same flat result.

Twelve bytes per vertex for positions and twelve bytes per triangle for indices, plus a small JSON header. A 200,000-triangle model with 100,000 vertices is therefore around 3.6 MB, and nothing in that is compressed. Indices are uint32 without exception, which costs four bytes where two would do below 65,535 vertices and removes a conditional that changes behaviour silently at a threshold.

If that number is too large for the page, the answers are upstream and downstream, not here: decimate the mesh in Blender or MeshLab first, and run gltf-transform afterwards for Draco or meshopt compression — remembering that both require the browser to load a matching decoder, which is its own cost on a page that shows one model.

If the model needs its textures, convert through Blender instead so the MTL and its images come with it. If the model has half a million triangles, decimate before converting rather than shipping it and hoping. If you need it to look smooth, deal with normals in the viewer or in the exporter, because this route will not give you any.

What this page is good for is the honest middle case: a clean OBJ of a part, a prop or a scan that needs to appear on a page as a shape, in one file, without uploading the model to anybody. That conversion runs entirely in your browser, with no engine to download and a 100 MB ceiling, and it produces a file every current web viewer will take.