What is a GLB file?

GLB is a binary format, meaningful only to a program that knows it. It stores shapes and coordinates rather than pixels, so it stays sharp at any size — a logo scaled to a billboard loses nothing. It is used for the web and handing a finished file over.

The extension is .glb, and the full name is Binary glTF. Both matter less than what the file can hold, which is what the rest of this page is about.

Khronos Group published it in 2016. The specification is glTF 2.0.

Age is worth knowing here for one practical reason: the older a format is, the more programs have had time to learn it.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

GLB stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

GLB can store an animation rather than a single still. That is worth knowing before converting one: a target that holds one frame keeps the first and drops the rest, usually without saying so.

Blender, three.js and Babylon.js read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

GLB is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

GLB is glTF packed into a single binary container: the JSON scene description, the geometry buffer and every texture, in one file with a small header. Nothing is added and nothing is left out — unpack a GLB and you have the .gltf, the .bin and the images that would otherwise sit in a folder.

That is the entire difference, and it is the reason almost everything published as 3D on the web is a GLB. A .gltf without its companions is a scene description referring to data that is not there, and sending one is the same mistake as sending an OBJ without its MTL.

A 3D model has more loose parts than most assets: a binary buffer, a base colour texture, a normal map, a roughness map, an occlusion map, an emissive map. A single object can be eight files, and a scene can be dozens.

One file removes an entire class of failure — a missing texture, a broken relative path, a folder that was zipped one level too high. It also removes network round trips: a browser fetching a GLB makes one request where the .gltf equivalent makes eight, and on a mobile connection the difference in time to first render is larger than the difference in bytes.

On Android, Scene Viewer takes a GLB, and the model-viewer element that most sites use for 3D takes GLB as its main source. Point a phone at a product page and the model that appears in the room came from one.

iOS is the exception worth knowing: Apple’s Quick Look uses USDZ, its own format, so a site supporting augmented reality on both platforms publishes a GLB and a USDZ side by side. The model-viewer element takes both and picks by platform, which is why product pages carry two files rather than one.

Textures dominate, not geometry. A model with four 4K maps is thirty megabytes before anything else is counted, and reducing them to 1K or 2K usually costs nothing visible at the size the model is actually displayed. Do that first.

Then Draco for the mesh, which frequently takes geometry to a fifth or a tenth of its size, and KTX2 with Basis Universal for the textures, which additionally lets the graphics card keep them compressed in memory rather than expanding them. Together these routinely turn a forty-megabyte export into something under three, and both are extensions — a viewer that does not implement them cannot open the file, so they belong at the end of the pipeline rather than in the master.

Editing and inspecting. A .gltf is readable JSON, so a wrong material value or a mis-scaled node can be found and fixed in a text editor, and a version control system can show a meaningful diff between two revisions.

A GLB is opaque. Any change means unpacking, editing and repacking, and a repository holding GLB files stores a new complete binary on every commit. The sensible arrangement is the same as everywhere else on this site: keep the .gltf and its assets as the working master, and produce the GLB as a build step for delivery.

Broadly, for a format ten years old. Every web 3D library, Blender, Unity, Unreal, Godot, Substance, Sketchfab, Android’s AR viewer, and the major asset marketplaces. Microsoft Office will even embed one in a document or a slide.

Where it is not accepted is anything built around older pipelines: 3D printing wants STL or 3MF, CAD wants its own formats, and film and VFX use USD or Alembic. GLB is a real-time delivery format, and asking it to do a manufacturing or a film job is asking the wrong file.

GLB and glTF convert between each other losslessly in both directions, because they are the same data with different packaging. Anything that reads one reads the other, and the conversion is packing or unpacking rather than translating.

From OBJ, FBX or a modelling program, expect materials to need attention: the physically based vocabulary GLB uses has no equivalent in OBJ’s MTL, so an imported model arrives grey and correct rather than textured and correct. To STL for printing, everything except the shape is discarded — materials, textures, animation, the scene hierarchy — and the mesh will usually need repair before a slicer will accept it.