GLB and glTF Explained: Which 3D File Format to Use for the Web (and AR)

Why the file format matters

A 3D model is not just a shape. It holds geometry that describes the surfaces, materials that decide how those surfaces look, textures that are wrapped around them, and sometimes animation or a scene hierarchy. The file format decides which of these things travel with the model, in what form, and how completely.

Choose the wrong format and the consequences are quite ordinary: a model that opens grey because its textures stayed behind, a chair that appears the size of a building, a product that lies on its side. None of these is a modelling mistake. They are delivery mistakes, and they are avoidable if the format is chosen at the start of the project rather than at the end.

For anything that will be shown in a browser, the format you will meet most often is GLB. This guide explains what it is, what it carries, where it fits among the other common formats, and where it does not fit. It is written for people who commission or manage 3D work rather than for developers, though the practical checks near the end are useful to both.

What is a GLB file?

GLB is the single-file, binary form of glTF. The name glTF stands for GL Transmission Format. It is an open standard maintained by the Khronos Group, and its purpose is to move 3D content efficiently between applications and, in particular, to load it quickly in a web browser.

The idea behind the standard is simple. The structure of the scene is described in a JSON text description, while the heavy data, meaning the vertex positions and the textures, is stored in compact binary form. glTF comes in two common packagings:

• .gltf: a readable JSON file plus separate files. The geometry usually sits in a `.bin` file and the textures in separate PNG or JPEG images. It is easy to inspect and edit, but several files must always be kept together with the correct names and paths.
• .glb: the same information packed into one binary file, with the JSON section and the binary data section side by side and the textures embedded.

For a website, the practical advantage of GLB is that one file means one request, and there are no file paths to break. You do not have to move four or five files around with their names intact. A single `product.glb` is enough.

So the answer to "GLB or glTF?" is rarely a matter of quality. They carry the same kind of content in two packagings. GLB is usually more convenient for delivery and publishing, while a separated glTF can be handy when you want to open and edit the contents by hand.

Why GLB is the usual choice for web 3D

GLB is common on the web for a handful of concrete reasons:

• Built with the browser in mind. glTF was designed for real-time rendering. Libraries such as Three.js and Babylon.js, and the `model-viewer` web component, read it directly.
• One file. Loading, caching and distribution are straightforward.
• Physically based materials as standard. glTF 2.0 describes materials with the metallic-roughness model, so how rough or metallic a surface is lives inside the file. The short version is that a PBR material behaves predictably under different lighting.
• An open standard. It does not belong to one company, and a wide range of tools and libraries support it.
• Compression extensions. There are standard extensions for making geometry and textures smaller, which I come back to below.

These properties make GLB a natural fit for interactive product models. If you want to see how one is placed on a page, the guide on how to add a 3D model to a website with model-viewer walks through the practical side.

What is inside a GLB file?

It helps to picture a GLB as a box with several compartments. A typical file holds:

• Scene structure: which object sits where, and which object is the child of which, with positions, rotations and scales.
• Geometry: vertex positions, faces, normals (the direction each surface faces) and UV coordinates.
• Materials: base colour, metalness, roughness, transparency and similar PBR values.
• Textures: image maps such as base colour, normal, roughness and metalness, ambient occlusion and emission.
• Optionally: animations, skeletons (skins) and cameras.

For a product model, the parts that matter most are almost always geometry, materials and textures. Lights and cameras are usually set up on the viewer side when the product goes on a web page, not stored in the file. This explains a very common surprise: "it looked different in Blender." The lighting and the surrounding environment are, in most cases, the job of the viewer, not of the file. The same GLB will look a little different in two different viewers because each one lights it in its own way.

UV coordinates deserve a mention because they decide how a texture sits on a surface. If they are poorly laid out, a perfect texture still looks wrong. For anyone commissioning a model, it is enough to know that UVs travel inside the file and that they should be checked.

If you are new to the wider process, what 3D product modelling is gives the background on how a product becomes a model in the first place.

How GLB compares with FBX, OBJ, USDZ and STL

Clients often ask in which format they would like the model delivered, and the honest answer depends on where it will be used. Here is how the common formats differ.

GLB and glTF are the standard for the web. Geometry, PBR materials and textures arrive together, they read quickly in a browser, and they are supported by web viewers, Android AR and many tools.

FBX is a proprietary format, yet it is widespread in film, animation and games. It can carry geometry, material references, skeletons and animation, and it is a frequent choice when a model or animation moves between studios. It is not directly useful on the web: it normally has to be converted and optimised first.

OBJ is old and simple. It carries geometry, UVs and, through a separate MTL file, basic material definitions. It does not carry animation or PBR materials. It opens almost everywhere, which is why it survives, but it is limited for modern product visualisation. Because the geometry, the material file and the textures live separately, losing one of them is exactly how a model ends up grey.

USDZ is the package Apple uses for augmented reality. If you want a model to appear in a room on an iPhone or iPad through AR Quick Look, you need USDZ. The usual approach for web AR is to offer GLB for the browser and for Android, and USDZ for Apple devices.

STL stores only surface geometry, with no colour, material or texture. It is common for 3D printing and unsuitable for product visualisation.

The Blender source file (.blend) is a different kind of object altogether. It is the editable scene, with its materials and settings, and it is the most valuable file if the product will change later. It is often not part of the standard delivery, so who receives it should be agreed at the start.

### A quick selection guide

• Rotatable product on a website: GLB
• AR on iPhone: USDZ (and GLB for Android)
• Animation hand-over or a game engine: FBX (or glTF)
• Simple, universal geometry exchange: OBJ
• 3D printing: STL
• Future editing: the .blend source

GLB is a container, not an optimisation

This is the point I would most like readers to take away. Using GLB does not mean the model is optimised.

A common assumption is that GLB is the web format and therefore must be light. In reality, GLB is a container, and it carries whatever you put into it. Five 4,096-pixel textures and a few million polygons placed in a GLB make a heavy file in a "web format". The format makes carrying easier; it does not make anything lighter. Making a model lighter is a separate piece of work, done in four places:

• Geometry. Reduce unnecessary polygons and remove surfaces that nobody can see, such as the inside of a closed body.
• Textures. Choose resolution according to how large the product will appear on screen, use modern compressed image formats, and discard maps that are not used. Unused textures that leak into the export are surprisingly common.
• Materials. Let surfaces of the same character share a single material instead of creating many near-duplicates.
• Compression. Apply geometry compression and texture compression, described next.

On file size, textures are usually the largest part of a GLB, so they are normally the first place to look.

Compression: three ways to shrink the file

For web models, file size translates directly into waiting time. Three approaches are used together.

The first is geometry compression. Draco and Meshopt are two widely used methods for glTF. Both reduce the size of vertex and surface data. Draco is older and more widespread, while Meshopt can decode quickly and also works well with animated models. Both require the viewer to support the matching decoder, so it is worth confirming that your target viewer does.

The second is texture compression. Textures can be reduced by choosing a smaller resolution, by using a format such as WebP, or by using KTX2 (Basis Universal), which can reduce both the download size and the amount of graphics memory used. Which of these suits a project depends on the viewer and the devices you need to reach.

The third is simplifying the model itself: removing unused objects, hidden interior faces and detail that will never be seen at the size the product appears.

Used together, these steps can bring a heavy file down considerably, though how far depends entirely on the model, and a result should always be measured on the real file rather than assumed. After compressing, test the final model on the devices your audience actually uses.

Axis, scale and units: the quiet problems

When a model moves between programs, the most troublesome problems are rarely a broken texture. They are concepts that everyone assumes are the same but that are defined differently.

The glTF standard uses metres as its unit and Y as the up direction. Blender uses Z as up. Blender's glTF exporter converts this by default, through the "+Y Up" option in the export panel, so in most cases the model stands upright on the web. The result can still surprise you when objects in the scene were rotated by hand, when scale was never applied to the object, or when the scene was built at an unusual size.

Scale deserves a separate warning. Suppose, hypothetically, that a product was built in centimetres while the scene unit is treated as metres. On the web it could appear ring-sized or building-sized. In AR the consequence is bigger: the model appears in your room at its real size, so the scale has to be right. A good habit is to build the product to its real-world dimensions and to apply the object scale (in Blender, the operation that bakes the scale values into the object) before exporting.

The position of the pivot, the origin point of the model, matters too. A pivot at the base of the product helps it sit correctly on the floor in AR and in viewers that ground the model.

A simple check catches most of these issues: open the exported GLB in a web viewer, and see whether the product looks the right size and rests on the ground. Axis and scale errors usually show on first sight. Doing this before delivery or publication costs far less than going back afterwards.

Where GLB is not the right answer

GLB is not the format for every job. In some cases something else is more appropriate:

• Heavy editing. If the model will be edited extensively in other 3D software, keep the source file. GLB is a delivery and publishing format, not a source.
• AR on iOS. Apple's AR Quick Look uses USDZ, so AR projects usually need both GLB and USDZ.
• Engineering and manufacturing. Work that needs tolerances and part data uses CAD formats such as STEP. GLB does not replace them.
• 3D printing. STL or a similar format is the usual choice.

GLB is excellent for showing a product on the web and in interactive use, but it is not the single format for every purpose. In a real project it is common to find the source file, the GLB and, where needed, a USDZ together.

Conversion and where information gets lost

Moving between formats can lose information, because not every format supports the same material system. Blender imports and exports most formats and is enough for the majority of conversions. Command-line tools exist for compressing glTF files and cleaning them up, there are converters for turning FBX into glTF, and Apple provides tools to produce USDZ from glTF and other formats.

What is most often lost are advanced material features, procedural textures and complex node networks, because the target format has no equivalent. The remedy is to build the material with simple PBR values from the beginning, or to bake complicated procedural detail into image textures.

For an important model, place a screenshot of the converted file next to the original render and compare them. It takes a few minutes and catches most surprises.

How to check a GLB file

When a GLB lands on your desk, whether you made it or someone delivered it, check a few things instead of using it blindly:

• File size. Is it suitable for your target? If it is large, which part is responsible, textures or geometry?
• Appearance. Open it in a web viewer. Do the materials, colours and surfaces look as you expect?
• Scale and orientation. Does it open at the right size and the right way up?
• Missing surfaces or textures. Are there holes at the back or underneath, flipped faces or missing textures?
• Material names. If you plan something interactive such as a colour picker, are the materials separated and given meaningful names?

None of this needs special software. A `model-viewer` page, the Three.js editor or a simple online glTF viewer is enough. What matters is seeing the file outside the program where it was made, in a real web viewer, and ideally on the platform it is meant for.

A GLB checklist for delivery

If you are commissioning 3D work, writing a short delivery specification saves a great deal of back and forth. A page is plenty. Include:

• the intended use: web, AR, print or animation
• the file formats required, such as GLB, USDZ and the source file
• scale and axis rules, with real-world dimensions where available
• a maximum file size and a texture resolution target
• a naming rule for files and materials, for example "leather_black" or "oak_natural"
• whether the source file is included, and who owns it

Then use the same list as a checklist at hand-over. It makes sure both sides expect the same thing, and it turns "this does not open for me" into a quick conversation. If third-party textures or ready-made models are involved, confirm their licences as well, since a texture with unclear rights is not something you want inside a commercial model.

A hypothetical example: a furniture brand wants a rotatable model on its site, AR on iPhone and a catalogue image. A sensible delivery list would be one optimised GLB for the web, one USDZ for iPhone AR, high-resolution PNG images for the catalogue, and optionally the source scene. If each file name includes the product name, version and date, finding and updating them months later is easy. Cost also depends on what the list contains, which is covered in the piece on what affects the price of 3D product modelling.

Common mistakes

• Assuming "GLB means optimised". The format gives no guarantee of lightness.
• Not keeping the source file. Editing backwards from a GLB is hard.
• Leaving the export settings at their defaults without testing. Scale, axis and applied modifiers can produce unexpected results.
• Inconsistent file and material names, which makes later work in code harder.
• Looking at a single viewer and calling it done. Lighting differs between viewers, so check at least on the target platform.

Where the format meets the design

I treat GLB as the last step in a chain, but the chain decides how it goes. First the form and proportions of the product are built, unnecessary geometry is removed, and materials and textures are kept simple. Only then is the model exported as GLB, compressed and tested in a real viewer. Knowing the target format from the start means materials follow glTF's PBR logic from the first day, and scale and axis are right before export, so there is little to fix at the end.

This matters even more when a product has options. In the Aura Reformer project, a set of six Pilates equipment products is shown in a web viewer with a 3D colour picker of 57 colours: 20 Aspendos, 29 Harşena and 8 Toskanto felt. A picker like that only works if the materials were separated and named properly in the model, which is a format and preparation decision made long before anyone clicks a swatch. The colour picker side is described in the 3D colour configurator for products article.

For me, the file format stopped being a small technical detail once I started producing 3D for the web. It became part of the design.

If you have a product that needs preparing as a web-ready GLB, the quickest start is to request a quote with a short brief of where the model will be used.

Photography or 3D for your product pages?

GLB is one half of the question: how to deliver. The other half is whether 3D is the right medium for a given product at all. For a comparison of the two approaches, see product photography versus 3D renders for e-commerce.

Frequently asked questions

Conclusion

GLB is a solid container for showing 3D products on the web, but lightness and quality depend on what goes into it. Decide the format at the start of the job, build materials, scale and file structure to suit it, keep the source file, and test the result in a real viewer. Handled that way, the file format stops being a late technical detail and becomes part of the design.