Skip to content
STLBench

Free online glTF viewer

glTF viewer that opens the .bin as well

Most .gltf files are only half a model: the JSON points at a scene.bin holding the vertices and a folder of textures beside it, and most web viewers stop there. This one does not. Hand over the rest — select the files together, drag the folder, or drag a zip of it — and the references resolve against what you dropped, read from this tab's own memory with nothing fetched and nothing uploaded. Then the measurements below: dimensions in millimetres, triangle budget, surface area and the space it encloses.

  • 100% free
  • No signup
  • Reads .bin and textures
  • Folders and zips
  • Nothing uploaded
Convert to

Drag a file anywhere on this page to open it. F fits the view, W switches shading, G the grid, R spins it.

How to open a glTF file

Three steps, and the first one is where most viewers give up.

  1. Drop the .gltf — and whatever came with it

    A self-contained glTF, one whose buffers are inlined as base64, opens on its own. The commoner split kind names a .bin and some images beside it, and those are wanted too: select them all in the file dialog, drag the folder they live in, or drag a zip of it. Nothing is fetched from anywhere; the siblings are read out of the same tab.

  2. Check what it was assembled from

    When a model comes from more than one file, the panel lists the files that were used. That is worth a glance: a texture that was not in the drop is the difference between a grey model and the one you exported, and seeing the list is faster than guessing which piece is missing.

  3. Measure it, in millimetres

    Bounding box, triangle count across every primitive in the scene, surface area, and volume when the surface is closed. glTF counts in metres by specification, and the figures here are converted for you — a part authored at 40 mm reads as 40 mm, not as 0.04, with the factor stated in the table.

Technical specifications

Extension.gltf — JSON glTF 2.0
Opens on its ownEmbedded exports, where buffers and images are inline data URIs
Opens with its siblingsSplit exports — pick the files together, or drop the folder or a .zip
KeptGeometry, PBR materials, node hierarchy
Not supportedDraco compression, KTX2 textures — both named in the error
UnitsMetres by specification, converted to millimetres in the panel

Frequently asked questions

My .gltf asks for a .bin file.

Then give it the .bin. A .gltf is a JSON description that keeps its vertex data in a separate binary buffer, usually called scene.bin, and its textures as ordinary image files beside it — that is the format working as designed, not a broken export. Select both files at once in the dialog, or drag the whole folder onto the page, or drag a zip of it: the references are resolved against the files you handed over, in memory, with nothing fetched and nothing uploaded. Re-exporting as .glb still works and is the better thing to send other people, but it is no longer something you have to do just to look at the model.

Why would anyone use .gltf instead of .glb, then?

Because a repository is not an inbox. The separated form keeps textures as ordinary PNG files that can be diffed, replaced and version-controlled independently, and the JSON is human-readable, so a material tweak is a text edit rather than a re-export. Pipelines typically author in .gltf and ship in .glb. The rule of thumb: .gltf while a model is being worked on by people who share a filesystem, .glb the moment it leaves that filesystem.

What does “embedded” glTF mean?

It is the third packaging of the same format: a .gltf whose buffers and images are written inline as base64 data URIs instead of as file references. It opens here with no siblings needed, exactly like a GLB, and it is the easiest fix if your exporter offers it. The cost is size — base64 inflates binary data by about a third, which is precisely why GLB exists as the binary alternative.

Is the geometry identical between .gltf and .glb?

Yes, byte for byte after decoding. They are two containers for one format, and every feature — the PBR material model, the node hierarchy, morph targets, animation, extensions — is expressible in both. Converting between them rearranges packaging and touches nothing about the mesh, which is why gltf-transform can do it losslessly in either direction and why a viewer can treat them with the same parser, as this one does.

It opened but everything is grey.

Check the line under the file name: it says whether this page found textures, vertex colours or no colour data. Grey with “no colour data” usually means the image files were not part of what you dropped — the geometry came through the .bin while the textures had nowhere to come from. The list of files used is printed above the measurements, so compare it with the folder. Grey with “textured” means the textures loaded but are themselves plain, which happens with placeholder materials from a modelling package.

Does it support extensions like Draco or KHR_materials_transmission?

Partly, and it says which. Draco compression and KTX2 textures both need extra decoders that this page does not ship, and both produce a named error explaining that rather than failing silently. The material extensions that three.js implements natively — clearcoat, transmission, sheen and the rest — are honoured when present. Anything unknown is ignored by the loader, which is what the specification requires: a viewer must render what it understands and not refuse the file.

About glTF and its three packagings

glTF 2.0 is a Khronos standard, and it is unusual among 3D formats in describing a result rather than a recipe. Its material model is physically based and fixed — base colour, metallic, roughness, normal, occlusion, emissive — so a file rendered in two different engines looks the same in both, which is not true of OBJ or FBX. Its buffers are laid out the way GPU memory wants them, so loading is close to a memcpy rather than a parse. Those two decisions are why it won the web and why almost every asset pipeline now ends in it.

The confusion is entirely in the packaging, which comes in three forms. Separated: a .gltf beside a .bin and image files, the working form for a repository. Embedded: one .gltf with everything base64-inlined, larger but self-sufficient. Binary: a .glb, the same content packed efficiently into one file, which is what should leave your machine. All three are the same format, and a viewer that opens one opens all of them — provided the parts are actually present.

It is worth being precise about what changed and what did not. The references inside a glTF are relative paths, resolved against wherever the file lives, and a browser really does hand a page only what was dropped on it — that isolation is a security boundary, not an oversight. What it will hand over, if you drop a folder rather than a file, is every file in that folder. So the references are resolved against those, held in memory and served to the parser without a single request leaving the tab. The boundary is intact; the difference is simply that you are allowed to give the page the whole set instead of one piece of it. If the aim is a printable file rather than a rendered one, note that neither form carries millimetres — the STL viewer explains what that costs.

Where your glTF is read

Every number on this page is worked out by JavaScript running in the tab you are reading it in. The model you open is read straight off your own disk — it is never uploaded, logged or kept, which is also why these tools carry on working after you disconnect from the network.

One clause specific to this page: dropping a folder means this page reads every file in it, and it is worth saying exactly what that means. They are read into this tab, used to resolve the model's references, and discarded when you load the next one. Nothing is sent anywhere, and nothing outside the folder you chose is reachable — the browser hands over what you dropped and nothing else.