WebP Converter: Compress App Images Without Artefacts

A webp converter can reduce comparable-quality JPEG image weight by typically 25–35% when you export lossy WebP at quality 75–85, then inspect the result at its shipped size on a real phone. Keep PNG for flat-colour UI artwork, sharp-edged graphics, and assets requiring transparency where lossy compression creates halos or banding. Export each raster asset at the required density—such as iOS @2x and @3x—rather than placing one oversized source image in every build.

Key takeaways

• •Comparable-quality WebP is typically 25–35% smaller than JPEG.
• •Quality 75–85 is the practical lossy-WebP range before visible artefacts commonly appear.
• •PNG remains appropriate for flat colour, sharp edges, and transparency-sensitive artwork.
• •Gradients reveal compression banding before detailed photographs because adjacent colours change in small steps.
• •iOS raster exports should include @2x and @3x variants instead of one oversized bitmap.

This guide is for mobile UI/UX designers, founders, and engineers who already export raster assets for iOS, Android, or mobile landing pages.

Time: 25 minutes · You'll need: Original PNG or JPEG exports, A physical iOS or Android phone, A WebP encoder such as Google WebP cwebp, ImageMagick or an equivalent image-inspection app, Xcode asset catalog or Android resource folders

What's on this page

1. •Classify each image before you compress it
2. •Export density variants to compress app images
3. •Convert with a webp converter at quality 75–85
4. •Inspect artefacts and package the chosen files
5. •Reference table

• •Common mistakes
• •FAQs

Compress app images with WebP, step by step

1. Classify each image before you compress it

Split the screen’s raster assets into photographs, illustrations, gradients, icons, and UI surfaces. Send photographic hero images and editorial imagery to lossy WebP first; comparable-quality WebP is typically 25–35% smaller than JPEG. Keep PNG for flat-colour artwork, sharp edges such as pixel-precise logos or line diagrams, and transparency-sensitive assets. A lossy edge against a transparent background can produce a visible halo when composited over a different screen colour.

Treat gradients as a separate risk group. Compression removes colour detail that looks redundant in a photograph, but a smooth gradient contains small, regular changes between adjacent colours. Those changes become discrete bands first, especially in large onboarding backgrounds and tinted panels. Record each asset’s source dimensions, current file size, transparency requirement, and the screen where it appears. The result is a conversion list with a deliberate PNG exception list, not a blanket format swap.

Tip: Do not convert a 24×24 UI icon to lossy WebP; its hard edges have too little visual detail to hide compression errors.

2. Export density variants to compress app images

Export only the pixel dimensions each platform will request. For iOS bitmap assets, provide @2x and @3x versions in the asset catalog when the asset must support those display scales. Name them as a single logical image set rather than shipping one large bitmap and scaling it down at runtime. A 3× source is not a substitute for a 2× source: it adds download or bundle weight and consumes more decoded memory when the app displays it at 2×.

For Android, place density-specific raster resources in the appropriate drawable-<density> directories, such as drawable-xhdpi and drawable-xxhdpi, rather than relying on one oversized drawable image. Android selects resources based on the device’s density. For a mobile landing page, create responsive image candidates matching the actual rendered widths and let the browser select an appropriate source. Compression cannot compensate for serving three times more pixels than the screen can display.

Tip: Measure the rendered image box in device pixels before resizing; an image that appears at 180 pt occupies 360 px on a 2× display and 540 px on a 3× display.

3. Convert with a webp converter at quality 75–85

Make a lossy WebP test export at quality 80, then compare it against the original at the exact dimensions used in the app. Quality 75–85 is the practical starting range: move toward 75 for detailed photographs that remain clean, and toward 85 for faces, text embedded in imagery, or subtle gradients. Do not judge the file at 400% zoom alone; inspect it at normal viewing distance on the target device.

To convert manually with Google’s encoder, run cwebp -q 80 input.jpg -o output.webp. Create additional candidates with -q 75 and -q 85, then retain the smallest file that has no visible change in the target screen. For a PNG that must retain exact edges or alpha, use lossless encoding instead: cwebp -lossless input.png -o output.webp, then compare its size with the original PNG. You can also batch-test the same inputs in floow.design’s /free-tools/webp-converter, using its resize option and live size comparison, but retain the same device review step.

Tip: Compare exports over both light and dark app surfaces; translucent or anti-aliased edges can fail on only one background.

4. Inspect artefacts and package the chosen files

Review every candidate on a physical iOS and Android device, not only in the design canvas. Check four areas at normal brightness: skin and skies in photographs, large colour gradients, text baked into images, and transparent edges over the screen background. Reject an export if you see blockiness, ringing around high-contrast edges, colour shifts, or banding. On gradients, look near the darkest and lightest stops first; those regions make reduced colour detail easiest to notice.

Add the approved density variants to the iOS asset catalog and Android resource directories, then build a release-like package. Confirm that the app requests the intended resource at each density and that no original PNG or JPEG remains duplicated in the bundle. For a landing page, verify the delivered response format and transferred bytes in a mobile browser’s network inspector. Keep the original master outside the shipped asset directory so future crop or quality changes do not start from an already compressed file.

Tip: A smaller file is a regression if it causes a user-visible band across a full-screen onboarding gradient; keep PNG or raise quality for that single asset.

Reference table

Image format and export decisions

Do it with the free WebP Converter

Batch-convert PNG, JPEG, WebP and AVIF in your browser, with a quality slider, optional resize and a live size comparison.

Open the WebP Converter → — free, no sign-up.

Common mistakes

Replacing every PNG with lossy WebP.

Keep PNG or use lossless WebP for flat colour, crisp edges, and transparency-sensitive assets. Test composited edges against every screen background.

Using one 3× export for all iPhone screens.

Provide @2x and @3x variants in an iOS image set. The 3× file has more pixels and decoded-memory cost than a 2× device needs.

Approving compression from a desktop preview only.

Review at the shipped display size on physical iOS and Android hardware. Gradients, dark areas, and translucent edges expose artefacts differently on phone displays.

Reducing quality until the file is smallest.

Start at quality 80 and compare 75, 80, and 85. Select the smallest candidate without visible artefacts in its actual screen context.

Frequently asked questions

Is WebP better than PNG for app images?

WebP is better than PNG for many photographic app images, but PNG remains the correct choice for flat colour, sharp edges, and transparency-sensitive graphics. Lossy WebP can introduce halos around alpha edges and banding in simple colour fields. Use lossless WebP only after checking that it actually reduces the specific PNG’s file size.

What quality should I use in a WebP converter?

Use WebP quality 80 as the first export, then compare quality 75, 80, and 85 on the target phone. The 75–85 range is a practical sweet spot for many app photographs, while large gradients and images containing text often need the higher end. Keep the smallest version with no visible artefacts at shipped size.

Why do gradients look bad after I compress app images?

Gradients look bad after compression because their adjacent colours change in small, regular steps that lossy encoding can turn into visible bands. A photograph’s texture can conceal similar colour loss, but a full-screen blue or purple gradient cannot. Test gradients separately, start near quality 85, and retain PNG when the banding remains visible.

Should I export @2x and @3x images or one large image?

Export @2x and @3x iOS image variants instead of using one oversized image for every device scale. iOS asset catalogs select the appropriate representation for the display scale, which avoids decoding unnecessary pixels. Android should similarly use density-qualified drawable resources so the system can choose a suitable bitmap.

How much smaller is WebP than JPEG?

Comparable-quality WebP is typically 25–35% smaller than JPEG. The actual reduction depends on image content, dimensions, and the quality setting, so measure each exported candidate rather than applying one assumed saving to an entire bundle. Photographs usually benefit more predictably than flat UI graphics.

Where this leaves you

The useful compression decision is not “convert everything to WebP.” It is choosing the smallest export that remains visually unchanged in the screen where users see it. Start with photographs at quality 80, compare 75 and 85, and preserve PNG for flat-colour, sharp-edge, and transparency-sensitive assets. Export density-specific files so the app does not decode pixels it cannot display. Your next action is to select the three largest raster files in the current build, create 75, 80, and 85 WebP candidates, and review them on one iOS and one Android phone.

---

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

---

Related

• •SVG to PNG Converter — Rasterise any SVG at 1x to 4x, or export every iOS scale and Android density as one archive.
• •Phone Mockup Generator — Drop screenshots into realistic iPhone and Android frames, then export every combination as PNG and SVG.
• •Splash Screen Generator: Launch Without Delay — Use a splash screen generator workflow to build iOS and Android launch screens that mask c
• •App Icon Generator: Design Icons at Every Size — Use an app icon generator workflow to prove one mark reads at 40px, then prepare correct i
• •Gemini 3.1 for Mobile App UI Design: 4 Real Prompts Tested Hands-On (2026) — I tested Gemini 3.1 Pro with 4 real mobile app UI prompts — fitness tracker, food delivery

Sources

• •Google Developers — WebP Compression Study
• •Google Developers — cwebp Encoding Tool
• •Apple Developer Documentation — Asset Catalog Format Reference
• •Android Developers — App resources overview