Reduce 3D File Size Without Losing Quality

Every 3D file stores three categories of data: textures, geometry, and metadata. Knowing how much each one contributes tells you where to focus.

Textures (color maps, normal maps, roughness maps, ambient occlusion) account for 60% to 90% of total file size in most models. A single 4096x4096 PNG with an alpha channel can weigh 30 MB or more on disk. Multiply that across four or five texture channels and you have a massive file before the geometry even enters the equation.

Geometry (vertex positions, normals, UV coordinates, indices) makes up most of the remaining size. A 500,000 triangle mesh stores roughly 25 MB of raw vertex data. Curved surfaces, boolean operations, and sculpted detail all increase triangle count.

Metadata (scene graph, material definitions, animation curves, bone hierarchies) typically accounts for less than 5% of file size. In rare cases, verbose formats like FBX embed camera data, lighting rigs, and editor state that inflate this category.

Because textures dominate, they are the most productive place to start.

Texture optimization delivers the largest file size savings with the least risk to visual quality. Three techniques work together: downsizing resolution, choosing the right image format, and combining textures into atlases.

Downsize resolution. Reducing a texture from 4096x4096 to 2048x2048 removes 75% of the pixel data. If the model displays at 400 pixels wide on screen, a 4K texture offers zero visible benefit over 2K. Use 2048x2048 for hero assets, 1024x1024 for secondary objects, and 512x512 or smaller for background elements. Always use power of two dimensions (256, 512, 1024, 2048, 4096) because WebGL and most game engines require them for proper mipmap generation.

Choose the right image format. PNG is lossless but large. Switch to JPEG at quality 85 for color and roughness maps where transparency is not needed. According to Google's own study, WebP achieves 25% to 34% smaller files than equivalent JPEG at the same visual quality. For models distributed on the web, WebP inside a GLB file is an increasingly practical choice.

Combine textures into atlases. If your model uses 10 materials with 10 separate texture sets, packing them into fewer atlas textures reduces both file size and rendering overhead. This works best when objects share similar texture properties and can be UV remapped to fit a single atlas.

After textures, geometry is the next largest contributor to file size. Reducing the triangle count shrinks the file and also makes the model faster to render.

Decimation is the most common automated approach. Algorithms like quadric edge collapse remove vertices that contribute the least to the surface shape. A 480,000 face model can typically be reduced to 120,000 faces (75% fewer triangles) with negligible visual difference. Photogrammetry scans can tolerate far more aggressive reduction because they often contain millions of redundant triangles.

Remove flat surface detail. A perfectly flat wall modeled with 10,000 triangles looks identical to one modeled with 2 triangles. Focus polygon density on curved surfaces, silhouette edges, and areas the viewer will inspect up close.

Bake detail into normal maps. High frequency surface detail (pores, fabric texture, carved patterns) can be transferred from a dense mesh to a normal map on a simpler mesh. This is standard practice in game asset pipelines, where characters go from millions of sculpted polygons down to tens of thousands with no visible loss.

Tools that handle decimation automatically:

• Blender's Decimate modifier (free)
• MeshLab's quadric edge collapse (free)
• gltf-transform simplify for glTF/GLB files (free, CLI)
• Polyforge (browser, no install)

Most 3D files contain wasted data that adds size without contributing anything visible. Cleaning this up before export is one of the easiest wins.

Remove internal geometry. Boolean operations and assembly workflows often leave faces hidden inside the model. These faces add to file size and rendering cost even though the viewer never sees them. In Blender, use Select Interior Faces to find and delete them.

Merge duplicate vertices. Imported meshes frequently have coincident vertices (two or more vertices at the same position) left over from modeling or conversion. Blender's Merge by Distance operation collapses these and cleans up the resulting topology.

Remove unused materials. Scenes accumulate material slots over time. Unused materials and their associated texture references add dead weight to the file. Delete any material not assigned to visible geometry.

Deduplicate instances. If your scene contains 50 copies of the same chair mesh, each stored as a separate object, you are storing that geometry 50 times. Converting duplicates to instances (references to a single mesh) can produce dramatic savings. One documented case reduced a scene from 4.8 MB with 832 duplicated meshes to 661 KB with 13 instanced geometries.

After reducing what goes into the file, compression reduces how much space it takes to store. Two systems dominate the glTF ecosystem.

Draco (developed by Google) uses quantization and entropy coding to compress mesh geometry. Typical compression ratios range from 5x to 12x on glTF models. Google's own benchmark shows the Stanford Bunny mesh dropping from 2.9 MB to 46 KB. The default 11 bit quantization introduces no visible quality loss on most models. However, Draco cannot compress morph targets or animation keyframes in glTF files, and the WASM decoder adds roughly 150 KB (gzipped) to the initial download.

Meshopt (by Arseny Kapoulkine) takes a different approach. It optimizes vertex data for GPU cache efficiency and then applies byte level compression. Unlike Draco, meshopt handles morph targets and animation data. The WASM decoder is only about 7 KB gzipped. Combined with standard HTTP compression (gzip or Brotli), meshopt achieves compression ratios close to Draco. One test showed a 29 MB model compressed to 2.5 MB (91% reduction) using meshopt with quantization.

Vertex quantization reduces the precision of vertex attributes from 32 bit floating point to 16 bit or lower integers. This step works with or without Draco and meshopt. For positions, 14 bit quantization preserves geometric accuracy. For normals, octahedron encoding fits each normal into 2 components instead of 3, saving an additional 33%.

For a deeper comparison of these compression systems in a web context, see the web optimization guide.

The file format you export to has a significant effect on size. Two models with identical geometry and textures can differ by 50% or more depending on the format.

GLB is the most compact general purpose 3D format. It stores all data (geometry, textures, materials, animations) in a single binary file. GLB files are roughly 33% smaller than equivalent glTF files because they use binary encoding instead of base64 for embedded data. For web delivery, e-commerce, and AR, GLB is the default recommendation from Google, Apple, and the Khronos Group.

FBX files are typically 50% to 80% larger than equivalent GLB files. FBX embeds textures by default, stores extensive metadata (cameras, lights, editor state), and uses no built in compression. Re-exporting an FBX can inflate the file further because tools like Maya resample animation curves during export. If your workflow starts in FBX, converting to GLB with Polyforge's converter is one of the fastest ways to reduce size.

STL stores each vertex redundantly for every triangle that shares it, so files are inherently larger than formats that index shared vertices. For 3D printing, 3MF is the modern alternative. It uses ZIP compression internally and stores each vertex only once. See the 3D printing preparation guide for details.

OBJ uses plain text to store vertex data, which makes files two to three times larger than binary equivalents. OBJ also lacks support for materials beyond basic Phong shading, animations, or compression. It remains widely supported, but GLB is a better choice when the receiving application supports it.

These numbers come from documented tests, not estimates. Each row represents a single technique applied in isolation unless noted otherwise.

The full pipeline result shows why stacking techniques matters. No single optimization achieves 97.8% alone, but applying texture, geometry, and compression optimizations together compounds the savings.

Each platform has its own requirements. This table summarizes the official recommendations as of early 2026.

For detailed breakdowns of AR platform specifications, see the AR model requirements guide. For format comparisons, see 3D file formats compared.

These are the errors that cause the most wasted time. Avoiding them will save you from frustrating results.

• Ignoring textures entirely. Many people jump straight to polygon reduction. Since textures account for 60% to 90% of file size, skipping them means missing the largest opportunity.
• Over-decimating without checking the result. Automatic polygon reduction on complex models can break geometry, collapse thin features, and distort UV mapping. Always compare the decimated model visually against the original.
• Using 4K textures for models displayed at 400 pixels wide. A 4096x4096 texture on a product thumbnail is pure waste. Match texture resolution to the display size.
• Applying Draco to very small meshes. The Draco WASM decoder is roughly 150 KB gzipped. For very small meshes, the decoder download can still cost more than the compression saves.
• Compressing multiple times. Running lossy compression repeatedly degrades quality without meaningful size reduction. Keep uncompressed originals and apply compression once as the final step before distribution.
• Leaving embedded media in FBX exports. Autodesk tools embed textures by default when "Embed Media" is checked. This duplicates every texture inside the FBX file, sometimes doubling or tripling the output size.
• Quantizing too aggressively. Reducing vertex precision below 11 bits can produce visible blockiness on smooth surfaces. Use 14 bits for positions and 10 bits for texture coordinates as a safe starting point.