Why are my Unity Addressable bundles so much larger than expected?

The most common cause is duplicate dependencies. When two Addressable groups both reference the same texture, material, or mesh that is not itself Addressable, Unity copies that asset into both bundles. A single shared texture can be duplicated across dozens of bundles, multiplying your total build size. Use the Analyze tool's Check Duplicate Bundle Dependencies rule to find these duplicates.

How do I use the Addressables Analyze tool to find duplicate assets?

Open Window > Asset Management > Addressables > Analyze. Select the 'Check Duplicate Bundle Dependencies' rule and click Analyze. The results show every asset that appears in multiple bundles. Click Fix Selected Rules to automatically create a new group for shared dependencies, or manually move duplicated assets into a shared Addressable group.

Should I use Pack Together or Pack Separately for Addressable groups?

Pack Together creates one bundle per group, which is efficient for assets always loaded together like a single level's content. Pack Separately creates one bundle per asset, which is better for assets loaded independently but increases the number of HTTP requests for remote bundles. For most projects, a middle ground works best: group assets by usage pattern and use Pack Together within each group.

How do content update restrictions affect Addressable bundle size?

Groups marked as 'Cannot Change Post Release' (static content) are frozen after the initial build. When you update assets in these groups, the Addressables system creates new bundles with the changes rather than modifying the originals. Over time this accumulates redundant data. Move frequently updated assets into groups marked as 'Can Change Post Release' to keep update bundles small.

Fix: Unity Addressable Groups Build Size Too Large

Quick answer: The most common cause is duplicate dependencies. When two Addressable groups both reference the same texture, material, or mesh that is not itself Addressable, Unity copies that asset into both bundles.

Here is how to fix Unity addressable groups build size too large. You build your Addressable groups and the output is hundreds of megabytes larger than the raw assets should total. Individual bundles are bloated, your download sizes are unmanageable, and you cannot figure out where the extra data comes from. The primary cause is duplicate dependencies: assets shared between groups get copied into each bundle independently, silently multiplying your build size.

Why Addressable Bundles Get Bloated

Unity's Addressable system packages assets into AssetBundles based on group configuration. When you mark a prefab as Addressable, Unity includes that prefab and all of its dependencies (textures, materials, meshes, shaders) in the same bundle. The problem starts when two prefabs in different groups share a dependency that is not itself Addressable.

Consider two groups: "Characters" contains a hero prefab and "Enemies" contains a boss prefab. Both use the same 4K texture for a shared environment material. That texture is not marked as Addressable. Unity has no way to share it between bundles, so it copies the full texture into both the Characters bundle and the Enemies bundle. One 4K texture becomes two copies, adding 20+ MB to your total build size from a single shared asset.

Multiply this across dozens of shared materials, textures, and meshes, and it is common to see Addressable builds that are 2-3x larger than necessary.

Use the Analyze Tool to Find Duplicates

Unity provides a built-in tool specifically for this problem. Open Window > Asset Management > Addressables > Analyze. Run the Check Duplicate Bundle Dependencies rule.

The results show every asset that is duplicated across multiple bundles, how many bundles contain it, and the size impact. This is the single most useful diagnostic for Addressable build size problems.

// Programmatically run the Addressables Analyze tool
using UnityEditor;
using UnityEditor.AddressableAssets;
using UnityEditor.AddressableAssets.Build.AnalyzeRules;
using System.Collections.Generic;

public static class AddressableAnalyzer
{
    [MenuItem("Tools/Analyze Addressable Duplicates")]
    public static void FindDuplicates()
    {
        var settings = AddressableAssetSettingsDefaultObject.Settings;
        if (settings == null)
        {
            Debug.LogError("Addressable settings not found");
            return;
        }

        var rule = new CheckBundleDupeDependencies();
        List<AnalyzeRule.AnalyzeResult> results = rule.RefreshAnalysis(settings);

        int dupeCount = 0;
        foreach (var result in results)
        {
            if (result.severity == MessageType.Warning ||
                result.severity == MessageType.Error)
            {
                Debug.LogWarning($"Duplicate: {result.resultName}");
                dupeCount++;
            }
        }
        Debug.Log($"Found {dupeCount} duplicate dependencies");
    }
}

After running the analysis, click Fix Selected Rules. This automatically creates a new Addressable group for shared dependencies and moves duplicated assets into it. Both original groups now reference the shared bundle instead of containing their own copies.

Organize Groups by Usage Pattern

The default approach of one group per content type (all textures, all prefabs, all audio) leads to large monolithic bundles. A better strategy is to group assets by when they are loaded together.

Create groups based on game context: "Level1_Assets", "MainMenu_Assets", "SharedUI_Assets". Assets within a group are loaded together, so bundling them in one bundle is efficient. Assets that are shared across multiple contexts should go in a dedicated shared group.

// Log bundle sizes after building Addressables
using UnityEngine;
using UnityEditor;
using System.IO;
using System.Linq;

public static class BundleSizeReport
{
    [MenuItem("Tools/Report Addressable Bundle Sizes")]
    public static void Report()
    {
        string buildPath = "Library/com.unity.addressables/aa";
        if (!Directory.Exists(buildPath))
        {
            Debug.LogError("No Addressable build found. Build first.");
            return;
        }

        var bundles = Directory.GetFiles(buildPath, "*.bundle",
            SearchOption.AllDirectories);

        long totalSize = 0;
        foreach (var bundle in bundles.OrderByDescending(
            b => new FileInfo(b).Length))
        {
            var info = new FileInfo(bundle);
            float sizeMB = info.Length / (1024f * 1024f);
            Debug.Log($"{info.Name}: {sizeMB:F2} MB");
            totalSize += info.Length;
        }

        float totalMB = totalSize / (1024f * 1024f);
        Debug.Log($"Total: {totalMB:F2} MB across {bundles.Length} bundles");
    }
}

Bundle Packing Mode

Each Addressable group has a Bundle Mode setting: Pack Together, Pack Separately, or Pack Together By Label.

Pack Together puts all assets in the group into a single bundle. This minimizes the number of bundles but means loading any asset from the group downloads the entire bundle. Good for assets always used together, like all assets for a specific level.

Pack Separately creates one bundle per entry in the group. This allows granular loading but produces many small bundles. Each bundle still includes its own copy of non-Addressable dependencies, which can actually increase total size if many assets share dependencies.

Pack Together By Label groups assets within the group by their Addressable labels into sub-bundles. This is a middle ground: you can label assets by sub-category (e.g., "high_quality" and "low_quality" within a "Textures" group) and get separate bundles per label.

Pack Separately with shared dependencies is the worst combination for build size. Each per-asset bundle gets its own copy of every shared dependency. Use the Analyze tool after changing packing modes to see the impact.

Content Update Restrictions

Addressable groups have an Update Restriction setting: Can Change Post Release or Cannot Change Post Release. This matters for games that use content updates (downloading new assets after the initial install).

Groups marked "Cannot Change Post Release" are considered static. When you build a content update, any modified assets in static groups get moved to a new bundle rather than updating the original. The original bundle remains unchanged for players who have already cached it. But this means the modified assets exist in both the old bundle (for backwards compatibility) and the new delta bundle, effectively doubling the size of those assets.

Move assets that change frequently (UI elements, balance data, seasonal content) into groups marked "Can Change Post Release." Reserve "Cannot Change" for truly static assets like core game meshes and base textures that will never be patched.

// Check group settings for content update configuration
using UnityEditor;
using UnityEditor.AddressableAssets;
using UnityEditor.AddressableAssets.Settings;
using UnityEditor.AddressableAssets.Settings.GroupSchemas;

public static class GroupSettingsAudit
{
    [MenuItem("Tools/Audit Addressable Group Settings")]
    public static void Audit()
    {
        var settings = AddressableAssetSettingsDefaultObject.Settings;

        foreach (AddressableAssetGroup group in settings.groups)
        {
            var schema = group.GetSchema<BundledAssetGroupSchema>();
            if (schema == null) continue;

            string updateRestriction = schema.GetType()
                .GetProperty("StaticContent")?
                .GetValue(schema)?.ToString() ?? "Unknown";

            Debug.Log($"Group: {group.Name} | " +
                     $"Bundle Mode: {schema.BundleMode} | " +
                     $"Entries: {group.entries.Count} | " +
                     $"Static: {updateRestriction}");
        }
    }
}

Related Issues

If bundles are the right size but loading is slow, check that you are not loading bundles synchronously on the main thread. Use Addressables.LoadAssetAsync instead. If content updates fail with catalog errors, ensure your remote catalog URL is correct and the catalog hash file is accessible. For memory issues after loading many bundles, verify you are releasing handles with Addressables.Release when assets are no longer needed.

Run the Analyze tool before every release build. A single shared 4K texture duplicated across 20 bundles adds 200 MB to your download for no reason.