To reduce a GLB file's size, first identify what occupies the bytes: geometry, textures, animation, or data you do not need. A polygon reducer helps with geometry, but a model with large embedded textures can remain heavy after most of its triangles are removed.
Use the workflow below to choose the right operation, compare the result, and avoid trading a smaller download for a broken model.
File size, triangle count, and memory are different budgets
A GLB's size on disk tells you how much data the file contains. Triangle count describes part of its geometry. Memory use after loading depends on how the application decodes, stores, and renders that data. Improving one measurement does not guarantee the same improvement in the others.
Consider a hypothetical 20 MB GLB containing 16 MB of textures, 3 MB of mesh data, and 1 MB of other data. If an operation halves the mesh bytes, the result is 18.5 MB: a 7.5% reduction overall. This is an accounting example, not a benchmark; halving triangle count does not necessarily halve mesh bytes.
Before editing, keep an untouched source file and record its size, triangle count, texture dimensions, and required animation clips. Also write down the destination: a web product viewer, a game engine, or another application. Its importer determines which export options are usable.
Choose the operation that matches the problem
| What you observe | What to try first | What to check afterward |
|---|---|---|
| Dense geometry with detail invisible at the viewing distance | Mesh simplification | Silhouette, holes, shading, UV seams |
| Large textures on a small on-screen object | Lower texture resolution | Labels, surface detail, normal maps |
| Geometry still occupies many bytes after simplification | Compatible geometry compression | Loader support and decoding time |
| High texture memory after loading | A supported GPU texture format | Appearance and device compatibility |
| Unneeded objects or animation clips | Remove only unused content | Every required scene and animation |
For a first geometry check, open the model in the polygon inspector. For a more detailed GLB inventory, the glTF Transform CLI provides an inspection command after installation:
gltf-transform inspect input.glb
Its report helps distinguish geometry, texture, and draw-call concerns. Save it alongside your baseline so you can compare the exported file, rather than relying on the settings you intended to apply.
Reduce triangles when geometry is the problem
Open the GLB in the polygon reducer, choose a modest reduction, and compare the original and reduced previews. Increase the reduction only while the shape and surface remain acceptable at the intended viewing distance. Download a separate copy for verification.
Be precise about percentages. Keeping 25% of a 200,000-triangle mesh targets 50,000 triangles, which means removing 75%. A control labelled “reduction” describes what is removed; a ratio labelled “remaining” describes what is kept. The exported count is the measurement that matters.
Inspect thin parts, curved silhouettes, small openings, and boundaries between materials. A chair leg disappearing is a more useful stopping signal than reaching an arbitrary percentage. For animated assets, also test poses and clips in the destination application: a static preview cannot confirm deformation quality.
If you are deciding between rebuilding the topology and simplifying an existing mesh, see how to make a low poly 3D model.
Resize textures before chasing a smaller mesh
When texture data dominates the file, review each image's purpose and on-screen size. A label that users zoom into may need more detail than the underside of a distant prop. Reduce resolution selectively and compare both close and normal viewing distances.
Texture dimensions also affect memory. As a simple calculation, a 4096 × 4096 image stored as uncompressed RGBA8 needs 64 MiB for its base level; 2048 × 2048 needs 16 MiB. These figures exclude mipmaps, duplicate copies, and other overhead. They are not predictions of the PNG/JPEG download size or of a GPU-compressed texture's allocation.
Check color textures, normal maps, and roughness maps separately. Look for blurry lettering, altered highlights, visible seams, and lost transparency. Keep a higher-resolution source so a poor export is reversible.
Geometry compression and KTX2 solve different problems
Simplification removes geometric detail. Geometry compression, such as Draco or Meshopt, changes how mesh data is encoded for delivery. It is a separate choice from how many triangles you want to keep; an optimization preset may combine several operations.
KTX2 with Basis Universal addresses textures. It can supply GPU-compressed texture data, reducing texture memory compared with decoded conventional image formats. It does not guarantee a smaller file than PNG or JPEG. The glTF Transform Basis Universal documentation also highlights quality tradeoffs for normal and material-property maps, so inspect those maps carefully.
Compression requires support in the receiving application. For example, three.js GLTFLoader exposes separate setup for Draco, KTX2, and Meshopt through setDRACOLoader, setKTX2Loader, and setMeshoptDecoder. Configure the relevant decoder or transcoder before shipping assets that require it.
Treat these as export-pipeline options to evaluate with a compatible tool. The polygon-reduction workflow above is not a claim that low-poly.com's reducer exports all of these compression formats.
Verify the GLB you will actually ship
Use a short comparison sheet rather than judging only the final megabyte count:
- File: original and exported byte size, plus triangle and vertex counts.
- Appearance: matching camera and lighting; inspect silhouettes, UV seams, transparency, and material boundaries in the 3D viewer.
- Behavior: required animations, scale, orientation, and materials in the actual destination application.
- Loading: repeat measurements on the same device and connection, distinguishing a cold-cache load from a cached load.
- Rendering: compare frame time in the real scene, with its lighting, shadows, and visible objects.
A smaller download is useful, but it does not establish a universal frame-rate improvement. For scene-level planning, use the polygon budget testing guide to connect asset decisions to measurements on your target hardware.
Common questions
Why is my GLB still large after decimation?
The remaining bytes may be in textures, animation, or other scene data. Inspect the exported file's contents before removing more geometry. You may have already reached the mesh's visual limit while leaving the largest component untouched.
Is there one safe GLB size for mobile or the web?
No single file-size threshold proves that a model will load quickly or render smoothly. Set a target for your own experience, then test its loading, memory use, appearance, and frame time on representative devices.
Should I start with compression or polygon reduction?
Start with inspection. If the mesh has unnecessary detail, test reduction. If textures dominate, start there. Evaluate compression once you know which formats the destination supports, and keep the smallest version that passes your quality and compatibility checks.