Convert glTF to GLB

There are two kinds of .gltf in the world and only one of them works here. Open the file in a text editor and look for the "buffers" array near the end. If the entry has a uri that starts with data:application/octet-stream;base64, every vertex in the model is inside that one file and the conversion will run. If the uri reads scene.bin or model.bin, the geometry lives in a second file that a single-file converter never sees.

That second shape is the more common one, because it is what most exporters produce by default, and it is why this page opens with the check rather than burying it in an FAQ. Dropping a separate-buffer glTF here produces an explicit message telling you the geometry is elsewhere and suggesting the .glb version instead — which is a real suggestion, since whatever produced the .gltf can almost always produce a .glb directly.

A glTF with external resources is a small graph of files held together by relative paths: the JSON, a .bin, and one image per texture. Every one of those paths is a way for the model to break. Move the JSON without its neighbours and it loads as nothing; serve it from a CDN with a different directory layout and the buffer 404s; attach it to a message and only one of the four files goes.

A GLB has none of those failure modes because there is nothing to lose. It is also one HTTP request instead of several, which matters on a page where the model is the thing the visitor came for. That single-file property is the entire reason the binary container is in glTF 2.0 in the first place, specified alongside the JSON form rather than bolted on later.

The output is a glTF 2.0 binary: a twelve-byte header whose magic spells glTF followed by a version number and the total length, then a JSON chunk, then a binary chunk. The JSON chunk is padded to a four-byte boundary with spaces and the binary chunk with zero bytes, which the specification requires rather than merely tolerates — several loaders reject a file padded the other way round.

Inside, vertex positions are written as float32 in a VEC3 accessor and triangle indices as uint32 in a SCALAR accessor, without exception. Narrower index types would save a few kilobytes on small models and would need a conditional that silently changes behaviour at 65,535 vertices, which is a bad trade for a converter. Every position accessor carries the min and max the specification asks for, so viewers frame the model instead of opening zoomed to nothing.

This converter moves geometry. A glTF that declares a metallic-roughness material with a base colour texture, a normal map and an emissive map converts to a GLB containing vertex positions, triangle indices and mesh names — and the material block, the images, the samplers and the texture coordinates are simply not written.

That is worth weighing against the reason you are converting. If the point was to bundle textures into one shippable file, this page does not do it and gltf-transform or the Blender exporter does. If the point was to get a single binary artefact out of a self-contained JSON — for a size test, a geometry-only preview, a placeholder in a scene — the result is exactly right and considerably smaller.

Animation channels and samplers are not read, skins and joint hierarchies are not read, and cameras and lights are not read. A rigged and animated character arrives in the GLB as the static geometry of whatever pose the vertex data describes, with no way to move it.

For a static prop, a piece of architecture, a scanned object or a printed part this costs nothing, because there was nothing to lose. For a character or a mechanism it is the whole model. There is no partial outcome here and no setting that changes it, so the honest guidance is to check what your glTF contains before converting rather than after.

The source scene is walked from its default scene index, and each node matrix is composed with its parent before the vertices are transformed by the result. Nodes described with separate translation, rotation and scale properties are converted to a matrix first, using the quaternion form glTF defines, so both authoring styles land in the same place.

The GLB that comes out has a flat structure: one scene, one node per mesh, no parenting, no reuse. A model whose glTF placed a single bolt mesh forty times through the hierarchy becomes forty meshes with forty copies of the vertices. The picture is identical and the file is larger, which is the trade every format without instancing forces.

Draco-compressed geometry stops with a message naming Draco. KHR_draco_mesh_compression replaces the plain buffer views with a compressed stream, and decoding it needs a library that is not shipped here. Re-exporting without Draco is a checkbox in Blender and a flag in gltf-transform.

Geometry stored as triangle strips, fans, lines or points is skipped rather than converted, because only glTF mode 4 is a triangle list. A file that contains nothing else ends with a message that no triangle geometry was found. A malformed JSON file — a truncated download is the usual cause — is reported as unreadable rather than parsed into something arbitrary.

An embedded glTF stores its buffer as base64, which costs four characters for every three bytes. Moving the same geometry into a GLB binary chunk removes that overhead, so a self-contained glTF usually shrinks by roughly a quarter on conversion before anything else is counted.

Then subtract everything the converter does not carry. For a model whose bulk was textures, the GLB can be a small fraction of the original and correspondingly bare. A useful sanity check after converting is the triangle count: the index accessor count divided by three should match what your source tool reported, and if it does not, the source contained geometry in a form that was skipped.

Nowhere. This pair runs as plain JavaScript in the page, with no WebAssembly module to fetch and no request carrying the model. The parse, the transform bake and the binary assembly all happen on your machine, which is why there is no queue and no per-file wait.

The free ceiling is 100 MB, and a self-contained glTF is the one format here likely to approach it, since base64 makes it the most inflated way to store the same mesh. If you are near that line, the model is almost certainly better served by exporting GLB directly from the tool that made it.