3D Model Compression: Shrink GLB Files by 90% Without Breaking Them
3D Model Compression: Shrink GLB Files by 90% Without Breaking Them
A 40MB GLB loads in 12 seconds on average broadband. The same model compressed properly loads in under two. That difference decides whether visitors interact with your 3D content or bounce — and it's why compression is the most underrated skill in web 3D.
This guide covers why 3D files balloon, the three compression layers you can apply, and how to hit specific size targets for web, AR, and game delivery.
Why 3D Files Get So Big
GLB files pack geometry, textures, and animations into one binary. Size accumulates across all three:
| Component | Typical share of file size | Why it balloons |
|---|---|---|
| Textures | 50–80% | 2K–4K maps at 32-bit color; multiple maps per material |
| Geometry | 20–40% | High polygon counts; 32-bit precision for every coordinate |
| Animation | 5–20% | Dense keyframes sampled per-frame for every bone |
AI-generated models and photogrammetry scans lean texture-heavy; DCC-authored assets lean geometry-heavy. Diagnosis comes first: open your GLB in a viewer with asset statistics and check where the megabytes actually live before choosing a compression strategy.
Layer 1: Texture Compression (the biggest wins)
Textures are almost always the dominant cost, and they compress dramatically:
Right-size your maps
A prop viewed at arm's length on a phone screen doesn't need 4K textures. Match map resolution to on-screen size: 1K covers most product viewers, 2K handles hero assets, 4K is for zoom-ins nobody performs on e-commerce pages. Halving texture resolution quarters its pixel count.
Use compressed texture formats
KTX2 with Basis Universal supercompression is the modern standard: GPU-native compressed textures that are 4–8× smaller than raw PNG while uploading faster and using less memory at render time. Unlike JPEG/PNG (which must be decompressed to raw pixels before rendering), KTX2 stays compressed on the GPU.
Strip what's unused
Generated and hand-assembled files routinely carry orphaned maps — textures referenced by no surviving material, duplicated images across materials, or full metalness-roughness maps on objects that render with base color only. Tooling that deduplicates and prunes unused images typically shaves 10–30% instantly.
Layer 2: Geometry Compression
Draco compression
Draco is Google's mesh compression codec, supported natively by Three.js, Babylon.js, <model-viewer>, and most web viewers. It quantizes and entropy-encodes mesh data:
- Typical result: 5–10× smaller geometry
- Quality cost at default settings: imperceptible for viewers, measurable for CAD reference
- Cost: decoding time (hundreds of milliseconds for large meshes) and a decoder dependency in your viewer
Draco needs decompressed input first — if your source GLB already has Draco applied, or fails to convert, run it through a 3D compression tool that handles decompression as part of the pipeline.
Meshopt compression
meshoptimizer (meshopt) is the alternative: a simpler, faster-decoding codec with an extension-based fallback story. Choose meshopt when decode speed matters more than maximum ratio, or when targeting viewers without Draco support.
Mesh simplification (decimation)
Compression codecs preserve vertex count — they make data smaller, not the mesh simpler. When triangle count itself is the problem (scans and AI output regularly exceed 500k triangles), decimate:
- Blender: Decimate modifier, collapse mode, 0.1–0.3 ratio for background assets
- Target budgets: 50–100k triangles for desktop web, 5–20k for mobile AR props
Best practice: simplify first, then compress — decimation shrinks the data that Draco then encodes, multiplying the savings.
Layer 3: Container-Level Wins
Gzip/brotli at the CDN
GLB is binary but still compresses further at the transport layer: enable brotli (or at minimum gzip) for .glb on your CDN or host. This is free 15–25% on most files and requires zero content changes.
Strip metadata and extensions
Exporter cruft accumulates: generators' custom extensions, KHR_materials_* extensions targeting features your viewer ignores, per-node metadata from DCC tools. Pruning unused extensions both shrinks files and improves viewer compatibility.
Size Targets by Delivery Channel
Work backward from where the model will load:
| Channel | Target GLB size | How to get there |
|---|---|---|
| E-commerce product viewer | < 3 MB | 1K textures, decimate to <100k tris, Draco |
| Mobile web / AR Quick Look | < 5 MB | 1–2K textures KTX2, Draco, prune animations |
| Desktop hero experience | < 10 MB | 2K textures, meshopt or Draco |
| Game console / desktop app | 20–50 MB | Quality-first; still strip unused maps |
The < 5 MB AR target isn't arbitrary: Apple's AR Quick Look warns or fails on larger files over cellular connections, and Android Scene Viewer's behavior is similar.
Step-by-Step: Compress a GLB in the Browser
No Blender or CLI needed for the standard pipeline:
- Open the 3D compression tool
- Drop your GLB — processing is local, nothing uploads
- Choose your compression settings: quantization (start at 14 bits), Draco on, prune unused data
- Compare the preview against the original — check silhouettes, texture sharpness, and any animations
- Download the compressed GLB with before/after stats
For most texture-heavy AI-generated models this single pass yields 70–90% reduction with no visible quality change. Iterate settings only if the preview shows artifacts — quantization below 10 bits can band curved surfaces.
Frequently Asked Questions
Does compression reduce visual quality?
Quantization and codecs introduce small precision losses that are invisible at proper settings (12–14 bit quantization). Aggressive settings (8-bit, extreme decimation) visibly degrade. Always compare previews at zoom before shipping.
What's the difference between Draco and just zipping a GLB?
ZIP/GZIP compresses bytes without understanding mesh structure; Draco compresses geometry semantics — it knows vertices connect in surfaces and quantizes accordingly. Draco routinely beats generic compression 3–5× on mesh data. Also: ZIPped GLB won't stream into viewers, while Draco-compressed GLBs decode natively.
Can I compress a GLB with animations?
Yes — animation data quantizes and keyframe-reduces like geometry. Dense mocap-style curves often thin 10× with no visible motion change. Verify the preview plays all clips before shipping.
Will Draco-compressed models work in Unity and Unreal?
Engines prefer uncompressed or their own formats at build time; Draco is a web delivery codec. Pipeline pattern: keep master assets uncompressed, compress a web-delivery variant, import the original into engines.
How small can a model get?
Texture-heavy files commonly reach 10× reduction total (textures + geometry + container). Geometry-only files with Draco reach 5–10× on the mesh portion. Claims beyond 20× usually mean aggressive decimation happened somewhere — check what survived.
Is there a file size limit for compression?
Browser-based processing means your device memory is the limit, not a server quota — desktops handle multi-hundred-MB inputs routinely. For giant scans, decimate first, then compress the result.
Compress Your First Model
Shrink a file right now and watch the before/after: open the 3D compression tool — free, browser-local, no sign-up. Pair it with the 3D converter if your source isn't already GLB.
