Compression was requested, but the texture imported uncompressed anyway

This is the failure mode that survives every audit that only reads import settings: the texture says Compressed, and it imported as RGBA32 anyway. Block compression formats have hard constraints on dimensions, and when a texture doesn’t meet them the importer quietly picks an uncompressed format instead. You get the memory cost of uncompressed art with the settings of compressed art.

What the scan looks at

For textures where compression was requested, the actual imported Texture2D.format for the active build target — the engine’s own verdict, not an inference from the importer. If the requested state is “compressed” and the real format is uncompressed, the rule fires. That’s why it has no false positives: it’s reading the result, not predicting it.

Why it happens

The usual causes, in order of how often they show up:

• ETC / ETC2 (Android) require both dimensions to be a multiple of 4. A 1023×512 texture will not compress. Unity does warn about this one, per texture, with the message people end up searching for verbatim: “Only textures with width / height being multiple of 4 can be compressed to ETC2 format”.
• PVRTC (older iOS targets) requires square power-of-two. 1024×512 fails; 1024×1024 works.
• Non-power-of-two with mipmaps can force a fallback depending on the platform and format.

Because desktop DXT/BC formats have their own alignment expectations, this isn’t a mobile-only problem — it turns up on Standalone builds too.

The one that makes people think the warning is lying

Max Size is applied before the check. A 724×1044 texture has both dimensions divisible by 4 — and if you set Max Size to 1024, Unity scales it down proportionally first, so what actually gets compressed is the scaled result, which usually isn’t a multiple of 4 any more. You then get a warning that appears to contradict the source dimensions.

So the number that matters is the imported size, not the size of the file on disk. That’s the whole reason this rule reads Texture2D.format after import instead of doing arithmetic on the source dimensions: it’s the only way to be right about cases like this one.

How to fix it by hand

1. Resize the source art to a compatible size — a multiple of 4 at minimum, ideally power-of-two. This is the fix that works everywhere, and it’s usually a crop or a re-export rather than a re-paint.
2. Or switch format: ASTC accepts dimensions that ETC2 rejects, and is the modern default for Android and iOS anyway. Set it explicitly in the platform override rather than leaving Auto to choose.
3. Reimport and confirm the format actually changed — the Inspector preview footer shows the imported format, which is the only thing worth trusting here.

What PerfLint does about it

Report-only, deliberately. Fixing this means changing the asset’s dimensions or committing to a platform format, and neither is a decision a tool should make for you behind a button. The finding names the texture, its dimensions, the format it actually got, and the memory that compression would have saved — enough to sort the list and hand the top of it to whoever owns the art.

Why the Inspector doesn’t warn you

Unity does surface the imported format in the texture preview footer, per texture, if you go and look. What it doesn’t do is tell you which of your textures asked for compression and didn’t get it — and that’s the whole problem: nobody clicks through 4,000 textures to compare requested against actual.