How to Reduce a 20 MB GLB to Under 1 MB

Reducing a 20 MB GLB below 1 MB is a 95% byte reduction. That is possible for many product, prop, and generated assets, but not through one compression checkbox. Geometry, vertex attributes, images, animation, scene structure, and container overhead have different causes and different safe treatments.

The correct workflow measures the file, assigns a visual contract, removes information in value order, and validates each stage. Preserve the original and write every output to a new path.

Define what under 1 MB means#

Decide whether the limit is exactly 1,000,000 bytes or 1 MiB, which is 1,048,576 bytes. A CDN dashboard may use decimal MB while a local tool displays binary MiB. Pick one release threshold and leave margin; targeting 950,000 bytes is safer than producing 999,980 bytes.

Write the target context:

runtime and loader versions;
supported glTF extensions;
lowest device and browser tier;
maximum and normal display size;
closest allowed camera distance;
lighting and background;
animation, skinning, and morph requirements;
required variants and selectable parts;
visual reference views;
acquisition and frame-time budgets.

An ecommerce thumbnail, a fullscreen jewelry viewer, and a WebXR object cannot share the same visual tolerance simply because each uses GLB.

Preserve a reproducible baseline#

Copy the 20 MB input into immutable source storage and calculate a content hash. Save the license and source metadata. Record the tool versions used to inspect and transform it.

Render 6–10 fixed reference views, including silhouette views, grazing highlights, closest inspection, back, underside if accessible, and important material details. Capture animation poses when relevant. Record bounds and physical dimensions numerically.

Run the Khronos glTF Validator before optimization. A malformed accessor, missing image, invalid bounds, or unsupported extension should not be hidden by a successful rewrite. Keep the original validator report.

Never overwrite the source during exploration. Use stage names such as 00-source, 10-clean, 20-geometry, 30-textures, and 40-delivery so a visual regression can be traced and rolled back.

Inspect the byte composition#

Use an inspector capable of reporting meshes, primitives, accessors, attributes, animations, images, materials, extensions, and byte allocation. GLTF Transform's inspect command, gltf.report, the Khronos Asset Auditor, and engine import reports can provide complementary evidence.

Build a table with:

GLB total bytes;
binary buffer bytes;
position, normal, tangent, UV, color, joint, and weight accessor bytes;
indices and component types;
triangle and post-split vertex counts;
primitive, material, node, and draw estimates;
image encoded bytes and dimensions;
animation sampler and key counts;
skins, joints, morph targets, and sparse accessors;
extensions used and required.

Suppose the 20 MB file contains 15.2 MB of PNG images, 4.2 MB of geometry, 400 KB of animation, and 200 KB of structure. That file will not reach 1 MB through Draco geometry compression alone. If images consume 76% of the source, texture decisions dominate.

Set a byte budget by subsystem#

Allocate the 950 KB delivery target before changing the asset. A practical example might reserve:

380 KB for base-color and emissive imagery;
220 KB for normal and material-property imagery;
250 KB for compressed geometry;
50 KB for animation;
50 KB for JSON, scene structure, and safety margin.

This is not universal. A matte untextured part can spend most bytes on geometry; a low-poly scanned object may spend 80% on color imagery. The value of a budget is that it reveals when one subsystem is consuming another's allowance.

Track actual and target bytes after every stage. Do not keep reducing a 140 KB mesh while 1.8 MB of textures remain.

Remove content that should never ship#

Delete editor cameras, lights, empty helpers, duplicate nodes, hidden high-resolution meshes, unused materials, unreferenced images, obsolete animation clips, collision meshes not consumed by the runtime, and construction geometry.

Prune unused accessors and buffer views with a glTF-aware tool instead of manually deleting JSON references. Deduplicate identical accessors, images, textures, samplers, and materials. Flatten redundant nodes only when it preserves animation and semantic selection.

If 4 materials reference byte-identical 2048-pixel base-color images, deduplication can remove 3 payloads without visual loss. If 40 primitives use copied versions of the same material, consolidation can reduce structure and runtime state even if the GLB byte saving is modest.

Reinspect and validate. A cleanup stage that changes the render indicates the supposedly unused data was not unused.

Reduce geometry by visual role#

Remove invisible internals and duplicate shells before decimation. Replace modeled micro-relief, screws, stitching, pores, and small bevel segments with normal or color detail where those features do not affect the visible outline or interaction.

Create protected regions for silhouette, openings, contact edges, thin parts, joints, and recognizable landmarks. Simplify broad, low-curvature interior surfaces more aggressively. Use a silhouette-aware or quadric-error method and review multiple camera distances.

For a static product, a sequence might move from 480,000 to 180,000 triangles by deleting hidden structure, to 65,000 through feature-aware simplification, and to 32,000 by baking fasteners and small bevels. A direct jump to 32,000 can collapse holes and produce uneven highlight flow.

Triangulate deterministically before the final bake. Regenerate or validate normals and tangents. Check UV stretch and islands around protected details. Vertex count may remain high if many UV seams, hard edges, material borders, colors, or per-corner attributes split otherwise shared positions.

Remove unused attributes. Tangents are unnecessary when no material samples a tangent-space normal map and the runtime does not require them. A second UV set, vertex colors, morph targets, joints, or weights should exist only for a consumed feature.

Simplify animation separately#

Trim unused clips and empty lead-in ranges. Remove constant tracks, reduce redundant keys within position, rotation, and scale error tolerances, and lower oversampled bake rates. Verify loop seams and extreme poses.

A 4-second rigid product animation sampled at 240 Hz contains 960 sample times per track. A verified 30 Hz or adaptive reduction can remove most keys. A fast mechanical snap may need additional samples near the event, so uniform deletion is not always safe.

Delete unused joints and limit influences according to the target runtime. Recheck skin deformation after geometry reduction; simplification can change weights near elbows, straps, and thin surfaces.

Do not compress an animation that the experience does not need. Removing it is cheaper and less failure-prone.

Resize and restructure textures#

List every texture by visual purpose, dimensions, encoded bytes, decoded memory, UV coverage, and closest projected size. A 4096 × 4096 RGBA image represents about 64 MiB at its top level when decoded, regardless of a much smaller PNG or JPEG payload.

Resize by evidence. Keep pixels for labels, faces, product identity, and high-frequency normal detail. Reduce uniform paint, hidden areas, undersides, and low-value roughness maps. A common first pass changes important 4096 maps to 2048, secondary maps to 1024, and minor maps to 512, followed by reference comparison.

Crop or repack wasted UV space. If the visible islands occupy 30% of a square image, 70% of its texels do not directly describe the surface. An atlas or UV repack can improve effective density, but it requires rebaking and can affect wrapping, mip bleed, and reusable materials.

Remove opaque alpha channels. Pack compatible grayscale signals only when the target material expects the chosen channel layout. Apply correct color spaces: base color and emissive are typically color; metallic, roughness, occlusion, and normal values are data.

Choose texture encoding for the runtime#

For conventional web images, test JPEG or WebP quality on base color and other suitable signals. Avoid lossy color codecs for normal maps without visual review, because block artifacts change lighting. Preserve alpha with a format that supports it only where alpha is required.

KTX 2.0 with Basis Universal can carry GPU-oriented textures through KHR_texture_basisu. ETC1S generally favors smaller transfer size; UASTC generally favors higher quality at larger size. The loader must configure a KTX2 transcoder and the supported-device path must be tested before making the extension required.

Generate mipmaps and inspect them at distance. A tiny top-level image without stable mips can shimmer. Texture compression should reduce network and GPU costs without turning text, edges, or normal detail into noise.

Compare encoded size, transcode time, first upload, GPU memory, and visual result. The smallest file can be the wrong choice if it adds a large first-use CPU task on the weakest phone.

Apply geometry compression last#

After topology and attributes are stable, apply Meshopt or Draco according to the loader contract. Compression makes retained data cheaper; it does not decide whether that data has value.

Meshopt-based glTF compression and mesh optimization can improve vertex ordering and compact attributes. Draco can produce strong geometry transfer reduction. Quantization can reduce attribute precision and bytes with lower decode complexity in some paths. The correct choice depends on supported extensions, decoder caching, worker behavior, and target measurements.

Test a cold load. Include decoder fetch and initialization, geometry decode, texture transcode, upload, shader compilation, and first correct frame. Save an uncompressed or differently compressed candidate when it provides faster readiness under the byte cap.

Never apply lossy geometry compression before final editing and then repeatedly decode and recompress. Maintain an intermediate with deliberate full-precision or controlled quantized data.

Iterate against a size ledger#

An example 20 MB progression could be:

Cleanup and deduplication: 20.0 MB to 17.4 MB.
Remove hidden geometry and attributes: 17.4 MB to 15.8 MB.
Simplify and rebake: 15.8 MB to 13.9 MB.
Resize and repack images: 13.9 MB to 3.4 MB.
Encode textures for delivery: 3.4 MB to 1.15 MB.
Optimize and compress geometry: 1.15 MB to 890 KB.
Metadata cleanup and final alignment: 890 KB to 872 KB.

The order makes the dominant saving visible. Your ledger may differ. Record visual failures as well as bytes so a rejected 760 KB candidate is not accidentally revived later.

If the file stalls above 1 MB, reconsider scope. A second texture tier, fewer animation clips, separate variants, or a lower default inspection distance may be more honest than severe global damage.

Validate quality and delivery#

Run the Khronos validator after every structural or extension change. Open the result in at least 2 independent viewers and the shipping runtime. Compare fixed images with overlays or perceptual metrics, then perform a human orbit under neutral and grazing light.

Check:

physical dimensions and root transform;
triangle, vertex, draw, image, and material counts;
silhouette at all approved views;
holes, thin parts, and negative space;
normal and tangent shading;
UV seams and mip behavior;
metal, roughness, alpha, and emissive response;
animation timing, loop, skin, and morphs;
cold request through first correct frame;
sustained frame time and memory;
HTTPS, MIME, CORS, range, and caching behavior.

Test the exact production URL on a lower-tier device. A local desktop viewer bypasses the network, CDN headers, decoder caching, and thermal conditions that the user experiences.

Under-1-MB release checklist#

The threshold uses an explicit decimal or binary definition with margin.
The 20 MB source, hash, license, reports, and reference views are preserved.
Bytes are attributed to geometry, attributes, images, animation, and structure.
A subsystem budget directs the work.
Unused and duplicate data are removed before lossy operations.
Geometry reduction protects silhouette and semantic features.
Normals, tangents, UVs, and animation are verified after topology changes.
Texture dimensions, UV coverage, channels, and color spaces are intentional.
Texture and geometry compression match configured runtime decoders.
A stage ledger connects each byte saving to visual evidence.
Validation, independent viewers, and target-device profiling pass.
The production URL delivers the exact approved hash.

Sources and further reading#

Reaching under 1 MB is a controlled allocation problem. Inspect first, spend bytes on visible value, remove rather than merely compress, and approve the 872 KB artifact only when it remains correct in the production runtime on the devices that made the limit necessary.