If you ship 3D content to the web, you've probably noticed: every viewer, every engine, every documentation page lands on the same format. glTF 2.0. It wasn't the first interchange format, and it isn't the most expressive — but it is the one the modern web actually loads.

Here's why, and what to do about the rest of the size budget once you've picked it.

What glTF gets right

It's designed for runtime, not authoring

FBX, COLLADA and Blender's .blend were designed for DCC tools — they capture the artist's workflow: layered modifiers, history, plugin-specific metadata, dozens of optional fields. Great for editing; expensive to parse, validate, and ship.

glTF was designed to be the last file in the pipeline. Meshes are stored close to how the GPU consumes them: tightly packed buffers, with views into those buffers describing attributes (position, normal, UV, tangent…) and indices. A loader can mmap the buffer and hand it to gl.bufferData with very little work in between.

One file (GLB)

A .gltf folder typically contains a JSON file, one or more .bin buffers, and a pile of texture images. Hosting that on a CDN means juggling MIME types and CORS for every byte. .glb packs everything into a single binary container that loads with one fetch. Same content, one HTTP request, no folder structure to worry about. You can move between them freely with our GLB → glTF and glTF → GLB tools.

Real ecosystem

<model-viewer>, three.js, Babylon.js, Filament, Unity, Unreal, Godot, Blender, Maya, Houdini, the Android Scene Viewer, Apple's Reality Composer — they all read glTF. Most of them treat it as the default. That isn't true of any other open format.

So what makes a glTF slow or big?

"Pick glTF" doesn't get you all the way to a fast load. A naïvely exported model can still be huge for two reasons.

Reason 1: too many vertices

The artist's high-resolution mesh might be 200,000 triangles. The viewer doesn't care — at typical web view distance and pixel density, half that is often indistinguishable, and a fifth of that is usually fine.

Reducing triangle count well is hard. You have to collapse edges in an order that preserves the silhouette, respect UV seams, and not mangle normals. That's exactly what meshoptimizer's simplifyMesh() does — and what our Simplify 3D Model tool exposes as a slider.

Reason 2: bad vertex order

This one is more subtle. The GPU has a small post-transform vertex cache — typically 16–32 entries. If two adjacent triangles share a vertex, and that vertex is still in the cache from the previous triangle, the GPU reuses it instead of re-transforming it. If the index buffer jumps around randomly, the cache is useless and every triangle costs three full vertex transforms.

Most exporters do not optimize vertex order. meshoptimizer's optimizeVertexCache() reorders triangles into strips that maximize cache hits. Same triangles, same look, often 2–3× less vertex shader work.

The same library has two more passes worth running:

  • optimizeOverdraw reorders triangles so opaque ones are drawn front-to-back, letting the depth test reject hidden pixels before the fragment shader runs.
  • optimizeVertexFetch reorders the vertex buffer itself so the GPU's L1 cache hits on every vertex pull.

All three are enabled by the "Optimize meshes for the GPU" toggle on every WebConverter 3D tool — including Optimize glTF/GLB if you already have a glTF and just want it faster.

Putting it together: a realistic web budget

For a model that's going to live on a product page or in an embedded viewer, a useful target is:

  • ≤ 5 MB total payload after Brotli compression
  • ≤ 50,000 triangles unless you really need the detail
  • Textures in KTX2/Basis if your viewer supports it (coming soon to this site — see the disabled toggle on the 3D tools)
  • One GLB request, not a .gltf + .bin + 12 textures folder

The path from "artist FBX" to "model that hits that budget":

  1. Convert FBX (or whatever you got) → glTF/GLB.
  2. Apply vertex-cache + overdraw + vertex-fetch optimization.
  3. Simplify if the triangle count is way over what you actually need.
  4. Re-encode textures as KTX2 / Basis Universal (coming soon to this site — the toggle is already wired).

Steps 1–3 all happen in your browser today with our 3D to glTF converter. Nothing uploaded, nothing throttled, no server roundtrip; your model goes from "way too big for the web" to "perfectly fine" in one drop.

Why "in the browser" matters

You could do all this in a desktop pipeline — gltfpack, Blender's exporter, three.js's optimization scripts. But every step that needs a local toolchain is a step a junior dev, a designer, or a content team can't take. A browser tool with a slider closes that gap. And because nothing leaves the tab, it's also safe to drop unreleased product assets, prototype scans, or anything else you wouldn't post to a third-party server.

That's the whole pitch of WebConverter: tools that would normally need a server, running entirely on your device. 3D to glTF is just the latest.

Ready to convert your images?

Try WebConverter Free