Why does my SpriteAtlas variant render blurry?

The variant's Scale factor is less than 1 (e.g. 0.5 for half-resolution). This is intentional for low-end devices. If you see blurry sprites on desktop, the wrong atlas variant is active. Check which variant loads via SpriteAtlasManager callbacks or log SpriteAtlas.tag at runtime.

What is the difference between a SpriteAtlas and a Variant?

A SpriteAtlas packs source sprites into a texture page at full resolution. A Variant references a master atlas and scales it down (0.25, 0.5, etc.) for lower-quality builds. Both share the same sprite references. Only one loads at runtime — the variant replaces the master when active.

Why does Include in Build affect my atlas?

If Include in Build is unchecked, the atlas is not packed into the build. Sprites that reference it load from individual textures instead, defeating the purpose of atlasing and potentially showing wrong resolution or pink errors if the source textures are also excluded.

Fix: Unity SpriteAtlas Variant Wrong Resolution

Quick answer: Verify the variant’s Scale factor matches your intent (1.0 = full, 0.5 = half). Check Include in Build on the master atlas. Use SpriteAtlasManager.atlasRequested to confirm which atlas variant loads at runtime.

Here is how to fix Unity SpriteAtlas variant wrong resolution. You create a master atlas for your HD sprites and a 0.5x variant for mobile. On mobile, sprites look correct at half-res. On desktop, sprites look blurry — the variant loaded instead of the master. Or vice versa: mobile loads full-res and runs out of memory. Atlas variant selection is implicit and easy to misconfigure.

The Symptom

Sprites from a SpriteAtlas render at the wrong resolution — blurry when full-res expected, or full-res when low-res intended. Sprites may also appear pink (missing atlas) or as their un-atlased originals (atlas not included in build).

What Causes This

Wrong variant active. SpriteAtlas variants are registered via callbacks. If your code or Addressables loads the wrong variant tag, the wrong resolution atlas activates. Unity does not auto-select based on device capabilities.

Include in Build unchecked. The master atlas must have Include in Build checked. Without it, the atlas is not packed and sprites fall back to individual textures — which may have different import settings.

Scale factor confusion. A variant with Scale = 0.5 produces textures at half dimensions. If you expected full resolution, check the variant settings. Scale = 1.0 on a variant is essentially a copy of the master (rarely useful).

Texture compression per platform. The variant inherits compression from the master but can override per platform. If the desktop override is ASTC and your desktop GPU does not support it, sprites decompress wrong.

The Fix

Step 1: Verify master atlas settings. Select the SpriteAtlas asset. Confirm:

Include in Build: checked
Type: Master
Objects for Packing: your sprite folders/textures
Platform overrides: correct compression per target

Step 2: Verify variant settings. Select the variant atlas. Confirm:

Type: Variant
Master Atlas: references your master
Scale: 0.5 for half-res mobile, 0.25 for very low
Include in Build: checked (for the platforms that should use it)

Step 3: Control variant loading via callback.

using UnityEngine;
using UnityEngine.U2D;

public class AtlasSelector
{
    [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
    static void Init()
    {
        SpriteAtlasManager.atlasRequested += OnAtlasRequested;
    }

    static void OnAtlasRequested(string tag, System.Action<SpriteAtlas> callback)
    {
        string path = IsMobile()
            ? $"Atlases/{tag}_mobile"
            : $"Atlases/{tag}";

        SpriteAtlas atlas = Resources.Load<SpriteAtlas>(path);
        callback(atlas);
    }

    static bool IsMobile() =>
        Application.isMobilePlatform;
}

The callback fires when Unity needs an atlas. You decide which variant to load based on platform, quality settings, or device tier.

Step 4: Log which atlas loaded. After the callback fires, log the atlas name to confirm the correct one was selected during testing:

Debug.Log($"Atlas loaded: {atlas.name}, tag: {atlas.tag}, " +
    $"spriteCount: {atlas.spriteCount}");

If the wrong atlas loads, the path logic in your callback is wrong. Fix the path and rebuild.

Addressables Integration

When using Addressables with SpriteAtlas, mark the atlas as addressable and load it via the Addressables API. Variant selection happens through Addressable labels or profile variables rather than the SpriteAtlasManager callback. Both approaches work; do not mix them.

Packing Preview

Select the atlas and click “Pack Preview” in the Inspector to see the generated texture page. Verify resolution matches your expectations. If the preview shows a 512x512 page when you expected 2048x2048, the Max Texture Size setting is capping it.

“Atlas variants are a quality slider. Make sure you are holding the right end of the slider for each platform.”

Related Issues

For sprite rendering issues, see Sprite Renderer Not Visible. For wrong sprite loading from atlases, SpriteAtlas Wrong Sprite Loading covers related bugs.

Include in Build checked, Scale factor correct, callback selects variant. Three things.