thecompressjpeg

How to compress images for a mobile app

App bundles are downloaded once over mobile data, and install rates fall as size rises. The rules differ from the web in ways that catch people out.

The essentials

iOS densities
1×, 2×, 3× — most current devices are 2× or 3×.
Android densities
mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi — the same idea, five buckets.
Best format on Android
WebP. Android Studio converts assets in place.
Best format on iOS
PNG for UI, HEIC or JPEG for photographic content.
Better than any bitmap
Vector — SF Symbols and vector drawables scale to every density from one file.
Delivery
App bundles ship only the densities each device needs. Use them.

Getting assets right

  1. Step 1: Use vectors wherever the artwork allows

    Icons, logos and simple shapes should be vector drawables on Android or SF Symbols and PDF assets on iOS. One file covers every density, stays sharp on any future screen, and is usually smaller than a single bitmap.

  2. Step 2: Export bitmaps at the densities that ship

    For photographic assets you need real bitmaps. Export 2× and 3× for iOS, and xhdpi through xxxhdpi for Android. Shipping only 3× and letting the device downscale wastes bundle size and costs decode time on every launch.

  3. Step 3: Convert Android assets to WebP

    Android Studio will convert a whole res folder in place, with a quality slider and a before-and-after preview. It is typically a 25–35% reduction across the asset catalogue for no visible change.

  4. Step 4: Ship app bundles, not universal APKs

    An Android App Bundle delivers only the density bucket each device actually needs, which often removes more from the download than any compression setting. iOS app thinning does the equivalent automatically.

  5. Step 5: Move large content off the bundle

    Anything not needed at first launch — onboarding illustrations, seasonal artwork, catalogue photography — belongs on a CDN or in on-demand resources. Install size is the number that affects conversion.

Details worth knowing

Why install size matters more than page weight

On the web a heavy page costs a slow load. In an app store it costs installs: conversion falls measurably as download size rises, and mobile networks apply their own warnings above certain thresholds, which turns a download into a decision.

The asset catalogue is usually the largest controllable part of a bundle. Code is what it is; images are frequently two to three times larger than they need to be, and nobody notices because it is a one-off download rather than a per-visit cost.

Density buckets, and the mistake people make

Both platforms pick an asset by screen density. iOS uses 1×, 2× and 3×; Android uses mdpi through xxxhdpi, which are the same multipliers under different names.

The common mistake is shipping only the largest and letting the system scale down. It looks identical, so it feels safe, and it costs twice: the bundle carries pixels no device on the low end will use, and every launch spends CPU downscaling. Export the buckets properly and let the delivery mechanism strip the ones each device does not need.

Format support, by platform

Android — WebP
Supported since Android 4.0 for lossy and 4.3 for lossless and alpha. Effectively universal now, and Android Studio converts assets for you.
Android — vector drawables
The right answer for anything that is not a photograph.
iOS — PNG
The default for interface assets, and what Asset Catalogs expect.
iOS — HEIC
Native, and roughly half the size of JPEG for photographic content.
iOS — WebP
Supported since iOS 14, so usable if your deployment target allows it.
Both — SVG
Not natively supported as an image asset on either. Convert to the platform's own vector format at build time.

Compress at build time, not by hand

Anything depending on a developer remembering to optimise an asset before committing it will drift within weeks.

Put the compression in the build: a Gradle task, an Xcode build phase, or a pre-commit hook that runs the assets through a compressor. Then it happens to every asset, from every contributor, permanently — which is the only version of this that survives a team.

Do it here instead

These run in your browser on any device, so nothing is uploaded and there is nothing to install.

  • Bulk compressor

    One setting across a whole folder, processed in parallel, downloaded as a ZIP.

    Open the tool

  • JPG to WebP

    Typically 25–35% smaller at matched quality. The standard web win.

    Open the tool

  • Resize image

    By pixels or percentage, aspect ratio locked, across a whole batch.

    Open the tool

  • Compress PNG

    Lossless by default, with transparency carried through untouched.

    Open the tool

Questions

Frequently asked questions

Every answer below is present in the page source, expanded, so it can be read without opening anything.

Should I use WebP in an Android app?

Yes. Support goes back to Android 4.0 for lossy and 4.3 for lossless and alpha, which covers effectively every device in use. Android Studio will convert an entire res folder in place with a quality preview.

Do I need 1× assets any more?

On iOS, rarely — current devices are 2× or 3×, and most projects have dropped 1×. On Android the low-density buckets still see some use on budget hardware, and app bundles mean including them costs nothing on devices that do not need them.

Can I just ship the 3× asset and let it scale?

You can, and it costs twice — bundle size for pixels most devices will not use, and CPU on every launch to downscale them. Export the densities and let app thinning or app bundles deliver the right one.

How do I reduce app size the most?

Move anything not needed at first launch off the bundle entirely — onboarding art, seasonal assets, catalogue photography — onto a CDN or into on-demand resources. That usually beats every compression setting combined.

Should app images be vector or bitmap?

Vector for anything that is not a photograph: icons, logos, illustrations built from shapes. One file covers every density, stays sharp on future screens, and is normally smaller than a single bitmap density.

Does image compression affect app performance?

Decode time does. Oversized images consume CPU and memory on every screen that shows them, which is noticeable on lower-end devices. Correctly sized assets help launch time and scrolling smoothness as well as download size.

From the blog

Related reading

More background from the blog.

  • Practical Guides

    How to Compress Images for a Website Without Wrecking Them

    Resize before you compress. Measured on one photograph: half the width at quality 80 produced a 16.4 KB file, while full width at quality 40 produced 20.6 KB and looked far worse. The order of operations matters more than the settings.

    8 min read

  • Image Formats

    WebP vs JPEG: Which Should You Use, and When JPEG Still Wins

    WebP produced a 27.0 KB file against MozJPEG's 41.1 KB on the same photograph at slightly higher measured fidelity — 34% smaller. It also produced a larger file than JPEG on random noise. The advantage is real and content-dependent.

    9 min read

  • Image Formats

    PNG vs JPEG: When to Use Each, With the File Sizes to Prove It

    PNG stored the same photograph in 1274.1 KB where JPEG needed 67.5 KB — nineteen times larger. On a flat graphic PNG won. On a smooth gradient PNG lost to JPEG by a factor of two, which surprises most people.

    9 min read