Browser 3D tools
Convert GLB to GLTF to inspect a re-exported mesh asset as JSON, a BIN buffer and available textures. Download the companion files together.
Source format
Target format
A binary GLB is convenient to distribute, but a readable scene description can be easier to inspect in an asset pipeline. The glTF output exposes the re-exported mesh and material references as JSON.
This conversion rebuilds supported model data. It is not a byte-for-byte extraction of the original GLB JSON, and it should not be used as an archival copy of animations or extension data.
A GLB to GLTF copy can be useful when a teammate needs to inspect material references or locate a supported image separately from the geometry. Use it as an accessible derivative of the model, while keeping the original binary asset for features that this mesh export does not reproduce.
The export writes separate resources, each with a distinct role.
The readable document describes the exported scene, meshes, materials and companion resources. GLB to GLTF generates this JSON from the imported mesh model; its names and structure need not match the document originally stored inside the GLB.
The binary buffer holds numerical mesh data such as positions and indices. It belongs with the JSON even though it is not readable as ordinary text. Downloading just the scene description leaves that geometry resource behind.
Supported material textures are written as separate images and referenced by the new document. A GLB to GLTF output may have one atlas or several maps; do not assume an image should resemble a screenshot of the complete object.
The generated JSON refers to its companion files by name. Save all outputs together so the receiving application can locate the buffer and images.
Changing model.bin to a different filename without updating the JSON breaks that connection. Moving only the .gltf document is similarly incomplete: it is the description of the asset, not necessarily all of its data.
Separate files can help a teammate find the image used by a material or understand which buffer supplies a mesh. This makes the export useful as an inspectable static asset.
Readability has limits. Editing a material value is different from editing vertex data, and comparing regenerated JSON is not a reliable way to recover the original authoring history.
For a small material experiment, separating the image from the buffer can make it easier to understand which resource is changing. GLB to GLTF does not, however, provide a JSON editor, texture-replacement interface or asset-versioning system. Make those changes in appropriate tools and keep the resources linked.
Not for this export. It references the accompanying BIN and any exported images, so send the complete file set.
No. The importer and exporter construct a new model description. The output should not be treated as a direct extraction of all original glTF properties.
Vertex positions are stored in the binary buffer rather than as an ordinary list in this JSON. Use a modelling tool for geometry edits.
The JSON still points to the previous relative filename or location. Keep the GLB to GLTF output layout intact, or update the resource reference to match the image’s new location.
You can edit a supported exported image or update its reference in an appropriate asset-editing tool. Retain the expected UV arrangement if you want the artwork to stay on the same faces. GLB to GLTF does not create a new unwrap for replacement artwork.
No. This route imports and re-exports supported mesh data rather than preserving a complete animated scene. Keep the original GLB and, where possible, the authoring project for animation tracks, skins and extension data.
