Compress Android Assets — Smaller Bundles, No Code Changes
Compress the images in your Android res/drawable folders before building — smaller APK and AAB size, no upload, no code changes.
Quick answer
Drop your Android project's res/drawable folders into TinyPixels before building. It compresses every PNG and JPEG across all density variants in place, shrinking your final APK or AAB size with zero changes to your layouts or code.
How to compress your Android drawable resources
Download and open TinyPixels
Free to install on Mac or Windows — no account needed to start.
Locate your res/drawable-* folders
Find them in your Android project's res directory, organized by density.
Drop the folders into TinyPixels
Compress icons, illustrations, and all density variants (mdpi through xxxhdpi) at once.
Rebuild your APK or AAB
Your next build ships smaller with no code or layout changes needed.
Why drawable size matters for Android apps
Every image in res/drawable gets bundled into the APK or AAB, multiplied across every density folder you provide (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi). Icons, illustrations, and onboarding images exported from design tools are frequently far larger than needed for the pixel densities Android actually renders them at.
Smaller APKs and AABs mean faster Play Store downloads, lower data usage for users installing over cellular, and — with Android App Bundle's per-device optimization — even smaller final downloads once Google Play splits resources for each device configuration.
No code changes needed
Compress in place — ImageView renders the same bytes, just smaller.
All density variants covered
Compress mdpi through xxxhdpi in the same batch pass.
Works alongside AAB splitting
Smaller sources mean smaller per-device downloads after Play's own optimization.
Faster builds and uploads
Smaller committed resources mean faster Gradle builds and Play Console uploads.
Every density bucket is a separate file to compress
Android's density-based resource system means the same logical image typically exists as several physical files, one per density bucket:
res/drawable-mdpi/icon.png # 1x baseline res/drawable-hdpi/icon.png # 1.5x res/drawable-xhdpi/icon.png # 2x res/drawable-xxhdpi/icon.png # 3x res/drawable-xxxhdpi/icon.png # 4x
Compressing only the xxxhdpi variant — often the one used for testing on a high-end device — leaves the mdpi through xxhdpi copies uncompressed, even though every one of them ships in the final package for devices that need that density.
Common mistakes with Android drawable resources
Compressing only the highest-density folder
Every density bucket you provide ships as a separate file — an uncompressed mdpi or hdpi copy still adds size, even if xxxhdpi is optimized.
Not using vector drawables where possible
Simple icons and flat-color graphics are often better served as VectorDrawable XML, which eliminates the multi-density PNG problem for that asset entirely.
Assuming AAB's per-device splitting makes source compression pointless
Google Play's dynamic delivery splits which density folder a device downloads, but it still delivers whatever file is in that folder — a bloated source is still a bloated download.
Skipping WebP for drawable resources
Android has supported WebP in res/drawable since API 18 (lossy) and API 21+ (lossless/transparency) — there's no compatibility reason to avoid it on any app targeting a reasonable minSdkVersion.
Frequently asked questions
How do I reduce Android app size from images?
Compress every image in your res/drawable-* density folders before building — icons, illustrations, and onboarding images bundled across multiple density buckets (mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) add up quickly. Compressing them with TinyPixels before adding to the project can shrink the final APK or AAB with no code changes.
Does compressing images affect Android ImageView rendering?
No. Android renders whatever image bytes are in the drawable resource — a properly compressed PNG or JPEG at the same resolution looks identical on device while taking up less space in the app package.
Should I compress images in every density folder (mdpi, hdpi, xhdpi)?
Yes. Each density variant is a separate file bundled into the APK or AAB. Compressing all of them — not just the highest density — reduces total drawable size proportionally.
Does Android App Bundle (AAB) already handle size optimization?
AAB lets Google Play generate optimized APKs per device configuration, splitting resources so each device downloads only what it needs. This works with whatever source images you provide — compressing those sources first still directly reduces the size each device ends up downloading.
Shrink your Android app today
Free to start. No credit card, no account, no cloud. See Pro pricing →
Related tools
Compress SwiftUI Assets
Shrink your Apple platform app bundle with local compression.
Compress Flutter Assets
Shrink your Flutter app bundle with local compression.
Batch Image Compressor
Compress thousands of files in one pass.
Compress React Native Assets
Shrink your React Native app bundle.
Image Compressor Hub
Every format, platform, and framework in one place.
Compress Xcode Assets
Shrink your iOS app bundle with local compression.
Compress Unity Assets
Shrink your Unity project with local texture compression.
Compress Electron Assets
Shrink your Electron app installer with local compression.
Read more: How to reduce your app size on mobile and desktop → · Fix your Lighthouse score where it actually matters →