How to Reduce Unity Game Size

Unity game size is decided at import and at build time, not by the format of the files in your art folder, which is why re-saving source art in a leaner format usually leaves the build the same. Four things actually move Unity build size: the import settings Unity applies when it re-codes an asset, which assets end up in the build at all, how much code and engine surface ships alongside them, and what is included in the first download.

Game size and build size mean the same thing here: the size of what you ship. That quantity gets measured at three different points, and the three numbers do not match.

Unity re-codes imported assets into its own internal formats, so the choice of source asset type is not relevant. The manual's worked example is a multi-layer .psd, which Unity flattens and compresses before the build either way: exporting that texture as a .png file does not make any difference to build size. The order that works from here is find, cut, then move out, with the last of those being Google Play specific.

Why Compressing Source Files Doesn't Reduce Unity Build Size

Source format is an authoring decision. By the time an asset reaches a build it has been through Unity's importer, and what the importer produced is what gets packed. Re-saving, converting, or file-compressing the asset in your art folder changes the thing Unity reads, not the thing Unity writes.

What that rules out is the format of the source file, not every property of it. Reducing a texture's resolution is a separate change from re-saving it in another format, and the statement above only covers the second.

Unity also includes every asset in the Resources folder in a build, used or not. A folder that accumulated placeholder art, an old UI atlas, and three versions of a sound effect ships all of it, which is why the manual's advice is to check that every asset there is used.

Auditing Resources is harder than auditing the rest of the project. Assets there are typically fetched by path at runtime rather than referenced in a scene or prefab, so the editor's reference search will not tell you whether one is dead. Finding dead weight in that folder means searching the code that loads it.

How to Find What Takes Up Space in a Unity Build

Unity writes a size breakdown into the Editor log on every build. Open the Console window (Window > General > Console), then the More menu (⋮) and Open Editor Log. What you get is a summary of assets broken down by type, followed by every individual asset listed in order of size contribution.

Read the type summary before the per-asset list. Textures, sounds, and animations typically take up the most storage, and a project that matches that profile needs a different plan than one whose largest line is code.

For a view that survives past the next build, the Build Report Inspector package adds an Inspector to the BuildReport file Unity generates on every build. That file lives at Library/LastBuild.buildreport, and the Inspector displays the build steps and the assets in the build.

One habit worth adopting: build an empty project with the same player settings and keep the result. That floor for the engine and runtime, separate from what your project contributes, turns a raw build size into a number you can act on.

Build Report vs APK vs Download Size

Three different numbers get called the size of the game, and they are produced by three different processes. Which one you are quoting decides whether a change you made looks like progress.

These are not three views of one number, and arithmetic between them does not mean anything. The gap between a build report and a local APK is a recurring question on Unity Discussions, where developers report a total in the low tens of megabytes alongside an APK several times larger. Unity does not document whether the Editor log figures are measured before or after compression, so that gap shows two measurements with different scopes rather than one wrong number.

Player download size is the figure that reaches players, and it is smaller than the bundle you upload. You upload an App Bundle, and Google Play's serving model generates and serves optimized APKs for each user's device configuration, so they download only the code and resources they need. The bundle you built is not the artifact anyone installs.

Two details belong with any download figure you quote. All Google Play size limits are based on compressed download size, and the sizes on the App size page are representative calculations for one reference device configuration — XXXHDPI ARMv8, or the closest supported configuration. The bundletool command line tool estimates the same figure before upload using a similar but not identical calculation.

Settings That Reduce Unity Game Size

The middle column below is the one that matters, because an optimization that relieves memory pressure and an optimization that shrinks the download are different work aimed at different complaints. Only settings the documentation names appear here, and the cost column carries only costs a page states.

Texture compression needs care, because two sources cover it and they measure different things. Unity lists compressed texture formats among the settings that affect build size, while Android's texture guidance for games discusses the same formats in terms of memory use and performance. That page reports ETC2 as supported by over 90% of active Android devices and ASTC by over 75%, and describes ASTC as generally the best primary option for modern games, with ETC2 as a fallback for devices that do not support it.

Code stripping fails differently from the rest of that table: the symptom is a crash, not a larger build. Managed code stripping removes unused or unreachable code through static analysis, which can significantly decrease an application's final size, and that analysis only includes code that exists at build time because code generated at runtime is not there to see. The stripping levels run Disabled (Mono scripting backend only), Minimal (the IL2CPP default), Low (marked for future deprecation and not recommended), Medium, and High, which calls for thorough testing with careful use of [Preserve] attributes and link.xml files. Reflection is where that testing earns its place: the Unity linker cannot always detect uses of reflection, so code that uses reflection or generates other code at runtime should be preserved explicitly.

Moving Assets Out of the First Download (Google Play)

This section is Google Play only. Other stores and other platforms distribute differently, and the mechanisms below are not portable to them. Google Play requires new applications to be AABs rather than APKs, and an AAB can be split into a base module and asset packs, while an APK build is split into a main APK and an OBB expansion file instead.

Play Asset Delivery is the mechanism for the asset-pack half of that. PAD is only available for Google Play, stores that do not accept AABs need the APK publishing format with expansion files, all versions of Unity from 2021.3 support PAD, and Unity does not support Play Feature Delivery.

Play Asset Delivery defines three delivery modes. The differences between them decide where a given asset should live, and only one of the three changes the figure a player sees before installing.

Delivery mode and store-listing size are documented separately rather than as cause and effect, and the last column is the one that changes a decision. An asset pack moved from install-time to fast-follow still downloads without the player doing anything, and it stops counting toward the number on your store listing.

Install-time packs also carry a storage requirement worth planning around. They need the same free space as the base APK — at least two times the size of all the asset packs — while fast-follow and on-demand packs need only a few hundred extra megabytes. A large install-time payload can turn into failed installs on devices that are nearly full.

Deciding what goes where is a judgment about your own game rather than something the documentation settles. The question that separates the cases is whether a player needs the content to finish the first session: the opening levels and the shell UI generally do, while later chapters, alternate language voice-over, and optional cosmetics generally do not. Content that only some players will ever see is the clearest candidate for on-demand.

Building asset packs out of an existing project takes one of two tools. The Addressables for Android package packs Addressable groups into Android asset packs and offers Texture Compression Targeting support, letting you pack different texture compression variants into those packs. On the Google Play side, Texture Compression Format Targeting puts textures compressed in several formats into one App Bundle and lets Google Play deliver the best supported format to each device, with download limits applying separately to each unique texture format.

What Reducing Build Size Costs You

Three of the costs involved are documented rather than hypothetical. Changing the build compression method can reduce application size and can increase loading times, which trades against a different player complaint than the one you started with. Raising the code stripping level shrinks the final application and increases the chance of removing something only reached at runtime, which is why the high setting comes with a testing instruction attached. Moving content out of the first download shifts the cost onto the network and onto the device's free space rather than removing it.

The sequence matters more than any individual setting. Reading the build report first tells you whether you are solving a texture problem or a code problem, and confirming which of the three sizes you are measuring tells you whether a change you already made did anything at all.

Unity Game Size FAQ

Does converting PSD to PNG reduce Unity build size?

No. Unity re-codes imported assets into its own internal formats, so the source asset type is not relevant, and exporting a texture as a .png file does not make any difference to build size. A multi-layer .psd gets flattened and compressed before the build either way.

Why is my APK bigger than the Unity build report?

The two measure different scopes. A build report covers the assets in the build, while the APK contains everything you built, across every architecture and configuration included. Unity does not document whether the Editor log figures are pre- or post-compression, so the difference cannot be read as a compression ratio.

Do fast-follow asset packs count toward the app size on Google Play?

No. Install-time asset packs contribute to the app size listed on the Google Play Store, while fast-follow packs do not, and fast-follow content downloads automatically once the app is installed without the user opening it. Whether on-demand packs contribute is not stated in Google's delivery documentation.

What managed code stripping level does IL2CPP use by default?

Minimal. The Disabled level is only available for the Mono scripting backend, and Low is marked for future deprecation and not recommended. High is the size-first setting, and it calls for thorough testing with [Preserve] attributes and link.xml files.

Sources

• Reducing the file size of a build — Unity Manual
• Managed code stripping — Unity Manual
• Configure managed code stripping — Unity Manual
• Preserving code using annotations — Unity Manual
• Optimize distribution size for Android — Unity Manual
• Play Asset Delivery — Unity Manual
• Addressables for Android — Unity package documentation
• Reduce your app size — Android Developers
• Play Asset Delivery — Android Developers
• Textures — Android game development
• Optimize your app's size — Play Console Help
• Understanding build sizes — Unity Discussions