3D File Size Budgets by Platform

A 3D file budget is the maximum amount of data your asset can contain and still work well on a given platform. Go over budget and one of three things happens: the platform rejects your upload, the experience loads so slowly that users leave, or the rendering device runs out of memory and crashes.

File size is only part of the equation. Polygon count determines how hard the GPU works per frame. Texture resolution controls how much video memory gets consumed. Draw call count affects CPU overhead. A complete budget accounts for all of these.

The numbers in this guide come from official platform documentation, developer guidelines, and published specifications. Where platforms provide recommended targets rather than hard limits, both values are noted. Recommendations are almost always worth following because they represent the threshold where most real users have a good experience.

The web has no single authority that enforces 3D file size limits. Instead, the constraints come from network speeds, browser memory limits, and Google's Core Web Vitals metrics that affect search ranking.

General web 3D. A well optimized three.js scene should target 2 to 5 MB total for all assets (geometry, textures, and materials combined). At 5 MB, a 4G mobile connection needs roughly 3 seconds to download the model. At 15 MB, that stretches to 9 seconds, and you will lose a significant portion of users before the model ever appears.

Draw calls. Keep draw calls under 100 for smooth 60 fps on mid-range devices. Every separate mesh with its own material generates at least one draw call. Merging meshes that share materials is the fastest way to reduce this number.

WebXR (browser based VR and AR). Meta's WebXR performance guidelines recommend keeping the initial scene load under 3 MB and the full scene under 10 MB. The visible triangle budget is approximately 50,000. Frame time must stay under 16 ms for 60 fps, with JavaScript execution consuming no more than 10 ms per frame. Research from Meta shows that a 3 second loading delay causes 40% engagement loss, and a 10 second delay loses 60% of users.

Texture memory. WebGL contexts on mobile devices typically have 256 to 512 MB of texture memory available. A single uncompressed 4096 by 4096 RGBA texture consumes 64 MB. Four of those textures (diffuse, normal, roughness, emissive) can exhaust mobile GPU memory entirely. Stick to 1024 or 2048 resolution per texture for web delivery.

Mobile AR platforms have the tightest budgets in the 3D ecosystem. The device is simultaneously running the camera, tracking the environment, rendering your model, and maintaining a stable frame rate.

Apple AR Quick Look (iOS/iPadOS). Format: USDZ. Apple does not publish a hard file size cap, but their reference models (like the iPhone 11 Pro sample at 4.7 MB) and developer forum guidance consistently point to 4 to 8 MB as the practical sweet spot. The polygon recommendation is approximately 100,000 for broad device compatibility, with newer devices (iPhone 12 and later) handling up to 200,000 triangles. Textures should not exceed 2048 by 2048 pixels per map.

Google Scene Viewer (Android). Format: GLB. Google recommends keeping models under 100,000 faces. There is no published hard file size limit, but practical testing shows that models over 20 MB cause issues on lower-end Android devices. Google recommends using Draco compression and reducing texture resolution to improve load times.

Snapchat Lens Studio. Total lens package: 8 MB hard limit. Triangle count: 100,000 total (60,000 for rigged/skinned meshes). Texture resolution: 2048 by 2048 maximum. RAM budget: 150 MB. Joint count: under 100. These are strict limits. Lenses that exceed them will not pass review.

Meta Spark AR (discontinued). Meta shut down the Spark AR platform in January 2025. AR effects for Instagram and Facebook filters are no longer accepting new submissions. The specs below are retained for historical reference only. Total effect size was 4 MB. Polygon count: under 50,000 triangles per object, 150,000 total per effect. Textures: 1024 by 1024 maximum.

If you are targeting multiple AR platforms, build for the strictest one first (Snapchat at 8 MB and 100k triangles) and scale up for more permissive platforms. This approach avoids rework and ensures your base asset works everywhere.

E-commerce 3D models are typically viewed one at a time on a product page. The budgets are more generous than AR because the model viewer is the primary focus of the interaction, not a real time overlay on the camera feed.

Shopify. Format: GLB. Upload limit: 500 MB. Recommended size: 4 to 5 MB for fast loading. Shopify's product media documentation notes that models exceeding 15 MB may be automatically optimized, which can reduce quality unpredictably. Shopify automatically converts GLB uploads to USDZ for iOS AR Quick Look, so a single GLB file covers both platforms. See the Shopify AR preparation guide for the full workflow.

Amazon 3D View. Format: GLB or glTF. Recommended file size: 5 MB or less. Triangle count: Amazon's seller guidelines recommend 20,000 triangles, though the system can technically accept more. Texture resolution: 1024 by 1024 pixels (PNG or JPEG). Animation is not supported.

Google Merchant Center (3D product listings). Format: GLB or glTF. Hard limit: 15 MB. Recommended: 10 MB. Texture resolution: up to 2048 by 2048 (4K textures are not supported). Models go through a review process that takes up to two weeks before appearing in Google Shopping results.

VR headsets render two views (one per eye) at high frame rates. This doubles the GPU workload compared to a flat screen. Budgets are tighter than desktop applications and vary significantly by headset generation.

Meta Quest 3 / Quest 3S. 8 GB RAM total. After the operating system, camera tracking, and Guardian boundary system reserve their share, approximately 4 to 5 GB remains for applications. Eye buffer memory alone consumes roughly 180 MB at the default resolution with 4x MSAA. Meta recommends using their texture streaming system to stay within budget rather than loading all textures at full resolution upfront.

Meta Quest 2. 6 GB RAM. Available to applications: roughly 3.5 GB. The reduced headroom means simpler scenes and smaller textures compared to Quest 3. Many developers target Quest 2 as the baseline because it still has the largest installed base.

Apple Vision Pro. For immersive full space experiences: 500,000 triangle limit. For shared space applications (where your content coexists with other apps): 250,000 triangles. Apple's WWDC 2024 session on spatial computing optimization recommends keeping under 100,000 triangles in the user's field of view at any given time. Formats: USDA, USDC, USDZ. Apple's Xcode compression pipeline can reduce asset sizes by roughly 75% (from 1.2 GB uncompressed to around 300 MB in one documented case). Web based Vision Pro content should stay under 5 MB per model.

Practical per scene budgets for standalone VR. On Quest 2, aim for 500,000 to 750,000 visible triangles. On Quest 3, you can push to 750,000 to 1,000,000 visible triangles. These numbers assume relatively simple shaders. Complex materials with multiple texture lookups, transparency, and post-processing effects will eat into your polygon budget. Draw calls should stay under 100 to 150 on Quest hardware.

Game engine budgets are the most variable because they depend entirely on your target hardware. A PC game with a GTX 4090 target can afford millions of polygons. A mobile game on a 5 year old Android phone cannot.

Unity (mobile). Unity's official optimization course for mobile recommends 300 to 1,500 polygons per mesh for on screen objects when many objects are visible simultaneously. For single model viewers or product configurators, Unity handles 100k to 1M+ polygons without issues. The constraint is not any single model but the total scene complexity: more objects on screen means fewer triangles per object.

Unity (desktop/console). Modern desktop games regularly use 10,000 to 100,000 triangles per character model and millions of total triangles per scene. Unity's HDRP (High Definition Render Pipeline) is designed for these workloads. LOD (Level of Detail) systems automatically swap in simplified meshes at distance.

Unreal Engine 5. Nanite, Unreal's virtualized geometry system, effectively removes traditional polygon budgets for static meshes. It streams triangle data at the pixel level, rendering only the geometry that contributes to visible pixels. Film quality assets with millions of polygons work directly in Nanite without manual LOD creation. For non Nanite meshes on mobile, Unreal recommends up to 65,535 vertices per mesh due to 16 bit index buffer limitations.

Godot 4. Godot does not publish official polygon budgets. The engine is lightweight and performs well with optimized assets, but its 3D renderer is less mature than Unity's or Unreal's for complex scenes. For mobile 3D with Godot, follow the same general guidelines as Unity mobile. Desktop projects can push further, but benchmark on your target hardware.

For a deeper look at how each engine handles 3D file imports, format support, and coordinate systems, see the game engine import guide.

Platforms designed for sharing and showcasing 3D models tend to have the most generous file size limits because they control the viewing experience and can optimize rendering on their end.

Sketchfab. Free accounts: 100 MB per upload. Pro accounts: 200 MB. Premium accounts: 500 MB. Sketchfab accepts dozens of formats including glTF, FBX, OBJ, BLEND, and STL. ZIP or 7z compression is supported to maximize upload capacity. Sketchfab processes models server side and generates its own optimized viewer, so there is no strict polygon limit, though extremely complex models may fail to process.

Facebook 3D Posts (discontinued). Facebook discontinued 3D posts. This feature is no longer available for new content.

3D printing budgets work differently from real time rendering. There is no frame rate to maintain. The constraint is your slicer software's ability to process the mesh and the print service's upload limits.

General guidance. Keep STL files under 50 MB and under 1,000,000 triangles. Most slicer software (Cura, PrusaSlicer, Bambu Studio) handles files in this range without issues. Beyond 1 million triangles, slicing times increase significantly and some slicers may run out of memory on machines with limited RAM.

Print services. i.materialise accepts files up to 100 MB. Materialise OnSite handles up to 500 MB. Shapeways accepts up to 64 MB for all file types. Most printing services prefer binary STL over ASCII STL because binary files are roughly one fifth the size for the same geometry.

3MF vs STL. 3MF files are typically smaller than equivalent STL files because 3MF uses compressed XML internally, stores vertex data more efficiently, and supports shared vertices (STL duplicates vertices at every triangle). For a model that produces a 30 MB STL, the 3MF equivalent is often 5 to 10 MB. 3MF also carries color, material, and build platform information that STL cannot. See the printing preparation guide for format selection advice.

This table summarizes the key budget numbers from every platform covered above. Use it as a quick reference when preparing assets for a specific target.

When people think about 3D file size, they think about polygons. But in most production models, textures account for 60% to 90% of the total file size. A model with 50,000 polygons and a single 4K uncompressed texture can easily reach 50 MB. The same model with a compressed 1K texture might be under 2 MB.

Resolution caps by platform. Most AR platforms cap at 2048 by 2048 pixels. E-commerce platforms generally accept 2048. Google Shopping explicitly does not support 4K textures.

Compression formats. PNG textures embedded in a GLB file are uncompressed in GPU memory. Switching to KTX2 with Basis Universal compression reduces texture size by 75% or more while maintaining GPU friendly block compression. WebP offers good compression for diffuse/albedo maps. JPEG works for textures where lossy artifacts are acceptable (roughness, ambient occlusion).

The power of two rule. GPU hardware works most efficiently with textures whose dimensions are powers of two: 256, 512, 1024, 2048, 4096. Non power of two textures get padded to the next power of two in video memory, wasting space. A 1000 by 1000 texture occupies the same GPU memory as a 1024 by 1024 one.

Per texture budget. For web and mobile delivery, keep individual textures at 1024 by 1024 or smaller when possible. Reserve 2048 resolution for hero product shots where texture detail drives purchase decisions. Use 512 for secondary materials and backgrounds.

The numbers above are for a single RGBA texture. A PBR model typically has 3 to 5 texture maps (base color, normal, metallic/roughness, occlusion, emissive). Multiply accordingly. A model with five 2K uncompressed textures adds up to 80 MB of texture data alone. The same model with 1K KTX2 compressed textures uses about 1.5 MB total.

For a complete walkthrough of texture compression strategies, read the file size reduction guide.

Once you know your target platform, here is the optimization order that delivers the biggest file size reductions with the least visual quality loss.

• 1. Compress textures first. This is almost always the highest impact change. Convert PNG textures to WebP or KTX2. Reduce resolution from 4K to 2K or from 2K to 1K. A single resolution step down cuts texture data by 75%.
• 2. Remove unused data. Delete hidden geometry, unused materials, empty nodes, and orphaned animations. Modeling tools accumulate these over time. Export with "selected only" to avoid pulling in the entire scene.
• 3. Reduce polygon count. Use mesh decimation (polygon reduction) to lower triangle count. A 50% reduction is often invisible on organic shapes. Hard surface models with sharp edges need more care, as decimation can round off edges.
• 4. Apply geometry compression. Draco or Meshopt compression can reduce geometry data by 70% to 95% without any visual change. This is lossless for the vertex precision you configure and has zero rendering cost after decompression.
• 5. Merge meshes where possible. Combine objects that share the same material into a single mesh. This reduces draw calls and eliminates per object overhead in the file structure.

Polyforge's optimizer handles steps 1, 3, and 4 directly in the browser. Upload your model, adjust the settings, and download the optimized result. No software installation required.