A Step-by-Step Guide to Reducing Unity Build Size Without Sacrificing Quality

Ever tried to upload a Unity game to a store only to see the file size balloon like a hot air balloon? It’s a common nightmare for indie devs, and it can kill your chances of getting noticed. Luckily, you don’t have to sacrifice art or sound to keep the build lean. Below is a practical, no‑fluff walk‑through that I use on my own projects at Pixel Forge Studio.

Why Build Size Matters

A smaller build loads faster, runs smoother on low‑end devices, and stays under the size limits of platforms like Google Play (100 MB) or the Nintendo Switch (2 GB). It also makes the upload process less painful and can shave off a few dollars on bandwidth if you’re self‑hosting. In short, a tight build is a friend to both players and developers.

Step 1: Audit Your Assets

The biggest chunk of any Unity build is assets—textures, audio, models, and shaders. Start by opening the Project > Statistics window. It gives you a quick glance at what’s taking up space.

Textures

  • Compress wisely – Unity offers several texture compression formats (ASTC, ETC2, DXT). Choose the one that matches your target platform. For mobile, ETC2 is a safe bet; for PC, DXT5 works fine.
  • Resize oversized images – If a 4096×4096 texture is only used for a small UI element, scale it down. A rule of thumb: never go higher than the maximum display resolution you need.
  • Mipmap settings – Turn off mipmaps for UI sprites and any texture that never gets viewed from a distance. This can cut size by 30 % or more.

Audio

  • Prefer Ogg Vorbis – It compresses much better than WAV or MP3 while keeping quality acceptable for most games.
  • Adjust import settings – Lower the sample rate to 22 kHz for background music and 44 kHz for important sound effects. Also, set “Load Type” to “Compressed In‑Memory” unless you need streaming.
  • Trim silence – Unity’s audio importer can automatically strip leading and trailing silence. Enable it to shave off a few kilobytes per clip.

Models and Meshes

  • Remove unused vertices – Use the “Optimize Mesh” option in the import settings. It merges duplicate vertices and reduces file size.
  • Simplify LODs – If you have high‑poly models that never get seen up close, create lower‑detail LODs and drop the high‑poly version from the build.

Step 2: Trim the Engine

Unity ships with a lot of code you may never use. Stripping it out is easier than you think.

  • Managed Stripping Level – In Player Settings > Other Settings, set “Managed Stripping Level” to “Medium” or “High”. Unity will automatically remove unused managed code.
  • Engine Code Stripping – Turn on “Strip Engine Code” (also in Player Settings). This removes parts of the engine that your project never touches, like the physics module if you’re doing a 2D game.
  • Linker Settings – For IL2CPP builds, add a “link.xml” file to tell the linker which classes to keep. This prevents accidental removal of reflection‑based code while still pruning the rest.

Step 3: Optimize Code and Plugins

Even a clean engine can be bloated by third‑party plugins.

  • Remove unused packages – Open the Package Manager and uninstall any packages you aren’t using (e.g., Unity Analytics, Ads, or the XR Toolkit if you’re not building for VR).
  • Conditional compilation – Wrap platform‑specific code in #if UNITY_ANDROID or #if UNITY_IOS blocks. This tells the compiler to exclude code that never runs on the target platform.
  • Avoid large libraries – Some assets bring in hefty DLLs (like full‑featured networking stacks). Look for lightweight alternatives or consider writing a small custom wrapper.

Step 4: Use Asset Bundles or Addressables

If your game has optional content (extra levels, DLC, high‑res textures), don’t bake them into the main build.

  • Asset Bundles – Create separate bundles for optional assets and load them at runtime. The main build stays small, and players only download what they need.
  • Addressables – This is Unity’s newer system that automates bundle creation and loading. It also supports remote hosting, so you can keep the base build under the store limit and stream extra content later.

Step 5: Test and Iterate

After each change, build a development version and check the size. Use the Build Report (found in the Console after a build) to see a breakdown of where space is used. If a particular step didn’t move the needle, revisit the settings—sometimes a single texture or audio file can be the culprit.

Quick Checklist

  1. Run the Statistics window – note the biggest categories.
  2. Compress textures and audio to the appropriate format.
  3. Enable Managed and Engine stripping.
  4. Remove unused packages and plugins.
  5. Split optional content into bundles or addressables.
  6. Build, review the report, repeat.

A Little Story from Pixel Forge Studio

When I first launched Pixel Pilgrims, the initial build was a hefty 850 MB. The store rejected it outright. I spent a weekend going through the steps above, and the final size dropped to 210 MB without any visible loss in art quality. The biggest surprise? A single 12‑MB uncompressed WAV file that I’d forgotten to compress. It taught me that even tiny oversights can blow up a build.

Reducing build size is not a one‑time task; it’s a habit you build into your pipeline. Treat asset import settings like a code review—check them before you commit. Over time, you’ll find the process becomes second nature, and your games will ship lighter, faster, and happier.

Reactions
Do you have any feedback or ideas on how we can improve this page?