Convert GLB to glTF

It reads the geometry out of the GLB and writes a new glTF around it. That is a rebuild, not a repack. The tools that repack — gltf-pipeline with --binary=false, or gltf-transform — keep the original document intact and only move the buffer out of the binary container, which means the material definitions, the texture references and the animation channels all survive verbatim.

Here they do not. The converter walks the scene graph, pulls out vertex positions and triangle indices, and builds a fresh document with one mesh per primitive and one node per mesh. If your reason for converting is "I want to edit the baseColorFactor and save it back", this is the wrong tool and gltf-transform is the right one. If your reason is "I want to see what is in this file", read on.

Both are glTF 2.0, the Khronos Group specification published in June 2017 with the binary container in it from the start. A .gltf is JSON, with the vertex data either in a .bin file next to it or embedded as a data URI. A .glb is the same JSON with the same buffer, concatenated into one binary file behind a twelve-byte header whose first four bytes spell glTF.

Inside a GLB the content sits in chunks: a JSON chunk tagged JSON and a binary chunk tagged BIN, each padded out to a four-byte boundary with the padding counted in the declared length, which is why every chunk length in a valid GLB is a multiple of four. That is the entire difference between the two extensions. Nothing about the model changes when you move between them — which is precisely why a converter that rebuilds the model, as this one does, is doing more than the extension change implies.

One file, always. The vertex data is base64-encoded into a data URI on the single buffer entry, so there is no .bin sidecar to lose and no relative path to break when you move the file. A conversion produces one download, and splitting the output into two files would make that untrue.

Base64 costs four characters for every three bytes, so the embedded buffer is about 33 percent larger than the binary it encodes, and the JSON around it is pretty-printed with two-space indentation on top of that. For a file you are going to open in an editor that is a fair trade. For a file you are going to serve to a browser it is not, and the GLB you already have is the better artefact.

The list is long and it is worth reading in full: PBR metallic-roughness materials, base colour, normal, occlusion, emissive and metallic-roughness textures, samplers and images, UV coordinates, vertex normals, vertex colours, tangents, morph targets, skins and joints, animation samplers and channels, cameras, lights, and every extension the file declares.

What survives is vertex positions, triangle indices and mesh names. The scene hierarchy survives only in the sense that its effect does — see the next section. This is not a limitation of the glTF format, which holds all of the above comfortably; it is a limitation of this converter, which carries geometry between six formats that agree on almost nothing else.

A glTF scene routinely places one mesh several times with different matrices — four wheels referencing one wheel mesh is the standard example. The converter walks the scene graph from the default scene, multiplies each node matrix by its parent, and applies the resulting world matrix to the vertices before writing them out.

The consequence is that the shape you see is correct and the structure is not. Four wheels arrive as four meshes with four sets of vertices in four different places, rather than one mesh instanced four times. Node rotation, translation and scale given as separate TRS properties are composed into a matrix first, in the quaternion order glTF defines, so a model built that way lands in the same place as one built with an explicit matrix.

Draco-compressed geometry stops with a named error rather than a broken file. KHR_draco_mesh_compression stores vertex data in a compressed stream that needs its own decoder, and that decoder is not shipped here. Re-export from Blender or run gltf-transform with Draco disabled and the file reads normally.

Primitives that are not triangle lists are skipped silently rather than mangled. glTF mode 4 is triangles; modes 0 through 3 are points, lines, line loops and line strips, and modes 5 and 6 are triangle strips and fans. A GLB containing only line geometry — a wireframe overlay, a debug path — produces the message that no triangle geometry was found, which is accurate.

Open the output and the accessors array answers most of the questions people convert a GLB to ask. Each mesh contributes a VEC3 float accessor for positions and a SCALAR unsigned-int accessor for indices; divide the index count by three for the triangle count, and read the vertex count straight off the position accessor.

The POSITION accessor also carries min and max, which the specification requires and which viewers use to frame the model. Those six numbers are the bounding box, and they are the fastest way to find out that a model somebody sent you is a thousand times too large or sitting nowhere near the origin. Mesh names come through from the source, so a multi-part model stays legible.

If the file is going onto a web page, keep the GLB. It is smaller, it is one request, and three.js, Babylon.js and model-viewer all load it directly. Converting to glTF for delivery makes the file larger and, through this converter, strips the materials that made it worth showing.

If you need to change something and save it back, use gltf-transform or the Blender glTF exporter. If you need to inspect a file quickly without installing anything, or you need a text artefact to diff against another export, this page is the short route. Being explicit about that boundary is more useful than a page that implies every GLB should become a glTF.

The conversion is plain JavaScript running in the page — no WebAssembly module to download, no upload, no queue. The file is read with FileReader-style APIs and the result is assembled into a Blob you then save. The free ceiling is 100 MB, which is a very large GLB by the standards of anything meant for the web.

Because the output embeds its buffer as base64 inside pretty-printed JSON, expect the .gltf to be larger than the .glb it came from even after the materials have been dropped — the geometry is the bulk of most models, and base64 inflates it. A 12 MB GLB whose geometry accounts for 9 MB of that lands around 12 MB again as glTF, with none of the textures.