Images are usually the heaviest thing on a page — often more than half its total weight, per Google's web.dev guidance. For Mobile Apps, that makes the format decision a performance decision, not a taste one. Here is the 2026 ranking, with the savings each choice buys.
Formats worth considering
| Format | Compression | Transparency | Animation | Support (2026) |
|---|---|---|---|---|
| WebP | Lossy and lossless | Yes | Yes | over 96% of browsers in use in 2026 (caniuse) |
| AVIF | Lossy and lossless | Yes | Yes | over 93% of browsers in 2026, including Chrome, Firefox, Safari and Edge |
| JPEG | Lossy | No | No | every browser and device made in the last 25 years |
| PNG | Lossless | Yes | No | every browser since the early 2000s |
| SVG | Vector | Yes | Yes | all modern browsers |
Five formats cover effectively every Mobile Apps scenario. What separates them is below.
WebP: the default in 2026
25-34% smaller than an equivalent JPEG, per Google's published study, with support across over 96% of browsers in use in 2026 (caniuse). For most Mobile Apps work that combination — smaller files, near-universal support, transparency and animation included — makes WebP the sensible starting point. The WebP converter turns existing JPEG/PNG libraries into WebP in batches.
AVIF for the heavy lifting
AVIF goes further: roughly half the size of a comparable JPEG, and about 20% under WebP. Encoding is slower and very old browsers miss it (over 93% of browsers in 2026, including Chrome, Firefox, Safari and Edge), so the classic pattern is AVIF first with a fallback. Try one hero image through the AVIF converter and compare.
Where the classics still win
JPEG remains the file that opens absolutely everywhere — email clients, ancient CMS installs, kiosk software. PNG keeps its role wherever Mobile Apps needs sharp edges, text or transparency: a 1080p screenshot is typically 150-400 KB; a 12-megapixel photo can exceed 15 MB.
Don't rasterize your logos
Logos, icons and diagrams belong in SVG: icons usually weigh 1-10 KB, less than a single photo thumbnail, and they stay crisp at any resolution. Exporting a logo as a 2,000-pixel PNG when an 8 KB SVG exists is the most common self-inflicted wound in Mobile Apps.
Putting it together
Photographs go modern (WebP or AVIF) with a JPEG fallback where compatibility is unknown. Graphics and UI go PNG or SVG. Everything gets resized to its real display dimensions before upload — serving a 4000-pixel image in an 800-pixel slot is pure waste — and below-the-fold images get loading="lazy".
Photoshop, Canva and Squoosh all export these formats one file at a time; for converting an existing library, a batch converter with a ZIP download is the time-saver.
What this means for page speed
Images are usually the heaviest asset class on a page, so format choice flows straight into Largest Contentful Paint — the Core Web Vitals metric Google weighs for ranking. Lighter images, earlier paint, better scores: the chain is that direct.
The compounding is what surprises people: 200 KB saved per image across a forty-image page is eight megabytes a visitor never downloads.
Measure before and after with PageSpeed Insights — the image-weight line item makes the improvement concrete instead of theoretical.
The three classic errors
Serving originals. Uploading camera files straight from the device puts multi-megabyte images behind every thumbnail. Resize to display dimensions first; the format choice comes second.
One format for everything. Photos, screenshots and logos compress on different curves — forcing them all into one format guarantees at least one of them is badly served.
Never measuring. PageSpeed Insights and Lighthouse both show exactly how many kilobytes your images cost. Run the test once before and once after converting, and the improvement stops being theoretical.
The metadata question nobody asks
Every photo from a camera or phone carries hidden baggage: capture date, device model, exposure settings and — on phones — often GPS coordinates. Conversion is one of the moments where that baggage can be kept or dropped.
Photographers archiving work want the opposite — capture data is part of the record — so they convert copies for sharing and keep JPEG originals untouched.
The practical rule: treat the original as the metadata archive and the converted copy as the public version. That division of labour answers most privacy and copyright questions before they come up.
Image SEO beyond the format
Filenames describe the subject in plain words with hyphens — search engines read them, and so do you in six months. Alt text describes the image for screen readers and image search in one natural sentence, not a keyword pile.
Dimensions in the HTML (width and height attributes) stop layout shift, the CLS half of Core Web Vitals. Large previews need one meta line — max-image-preview:large — for Google Discover to show your images at full size.
None of these depend on the format, and all of them compound with it: a light, well-described, properly-sized image is the complete package for Mobile Apps.
Where the rules bend per platform
WordPress converts uploads to WebP on modern versions but keeps the original — uploading lighter files still pays. Shopify and most e-commerce platforms recompress aggressively; feed them the highest-quality source and let the CDN do the dirty work.
Email is the conservative corner: stick to JPEG and PNG, keep total weight low, and assume the oldest client in the audience.
Mobile Apps: quick decisions
Photos and hero images: WebP, or AVIF where you control the stack. Logos, icons, diagrams: SVG, with PNG as the raster fallback. Screenshots and UI captures: PNG.
Email attachments and downloads: JPEG, because it opens on whatever the recipient has. Short animations: animated WebP over GIF — same clip, a fraction of the megabytes. Print handoffs: TIFF or high-resolution PNG, never a web-compressed file.
Tape this list next to the upload button: every Mobile Apps decision above repeats weekly, and deciding once beats re-debating it per file.
Measuring the result
Run the page through PageSpeed Insights before touching anything and note two numbers: total image weight and Largest Contentful Paint. Those are your baseline.
Convert the images, redeploy, run the same test. Lighthouse in Chrome DevTools gives the same data offline if you prefer testing before going live.
Keep the before/after screenshots: for client work in Mobile Apps, a 40% image-weight drop is the easiest deliverable you will ever present.
What the savings look like at scale
Sketch a typical Mobile Apps page: 25 images averaging 350 KB as JPEG is 8.75 MB of pictures. The same set as WebP, at a conservative 30% saving, drops to about 6.1 MB; as AVIF, near 4.4 MB.
Multiply by traffic and the sketch becomes a bill: at 10,000 page views a month, the WebP move alone spares roughly 26 GB of transfer — bandwidth your host does not invoice and your visitors do not wait for.
These are envelope numbers, deliberately conservative; real galleries usually beat them because photo-heavy pages have the most to give.
Setting a team standard
Solo habits break the day a second person uploads. A one-paragraph internal rule — which formats for which asset types, maximum dimensions, where masters live — outperforms any amount of after-the-fact cleanup.
Put the rule where uploads happen: a pinned note in the CMS, a line in the project README. Standards work when they are visible at the moment of decision.
The short version
WebP first, AVIF where you control the stack, JPEG as the universal envelope, PNG and SVG for graphics. Resize to display dimensions before anything else. Measure once before and once after — the delta is the whole argument.
Shipping this without breaking things
Week one: audit. Pull the ten heaviest pages from analytics, note their image weight, and convert only those assets. High-traffic pages pay back first and surface problems fastest.
Week two: templates. Point new uploads at the chosen formats — the WebP converter handles the backlog in batches — and add width and height attributes wherever they are missing.
Keep a one-line changelog of what was converted when — six months later that note answers every "why does this page look different" ticket in seconds.
What the CDN adds on top
Formats decide the floor; delivery decides the rest. A CDN with automatic format negotiation serves AVIF or WebP to capable browsers and JPEG to the stragglers — from a single uploaded master.
Responsive markup does the same for dimensions: srcset and sizes let the browser pick the smallest adequate file, so a phone never downloads a desktop hero image.
Stack the three layers — right format, right dimensions, right delivery — and each multiplies the others; that is where the dramatic before/after screenshots come from.
Further reading on the formats
Every recommendation above unpacks further: our WebP format guide, our AVIF format guide and our PNG format guide cover the three workhorses in depth.
For the hands-on path, the JPEG to WebP guide walks the exact conversion most Mobile Apps libraries start with.
Accessibility: the other half of image work
Alt text is the cheapest professional upgrade in Mobile Apps: one natural sentence describing what the image shows and why it is there. Screen readers speak it, image search indexes it, and broken-image states display it.
Decorative images — dividers, ambient backgrounds — take an empty alt attribute instead, which tells assistive tech to skip them. Describing decoration is as unhelpful as ignoring content.
Text baked into images deserves suspicion: it cannot be read aloud, translated, searched or resized, and it blurs on the wrong screen density. If the words matter, put them in HTML next to the image, not inside its pixels.
Accessibility and SEO reward the same habits here, so the effort pays twice on every single asset.
Contrast check last: text or icons over photos need a tested overlay or scrim, because a hero that is legible on your monitor can vanish on a dim phone in sunlight.
One anti-pattern to retire: pasting the filename or a keyword list into the alt attribute. Assistive tech reads it aloud verbatim, and search engines discount it — a plain descriptive sentence beats both habits with less effort.
Frequently Asked Questions
What single format should I pick for Mobile Apps if I must choose one?
WebP. It compresses 25-34% under JPEG, supports transparency, and reaches over 96% of browsers in use in 2026 (caniuse) — the rare case where the convenient answer and the technically correct one match.
Is JPEG obsolete in 2026?
No — it is the universal fallback. Anything that must open in unknown environments (email attachments, downloads, legacy systems) still travels safest as JPEG, even when your primary delivery is WebP or AVIF.
How much speed do modern formats actually buy?
On image-heavy pages, converting a JPEG library to WebP typically trims a quarter to a third of image weight; AVIF roughly halves it. Since images dominate page size, that translates directly into faster loads and better Core Web Vitals.
Should logos be PNG or SVG?
SVG whenever the logo exists as vector art — a few kilobytes, infinitely sharp. PNG is the fallback for raster-only logos or platforms that reject SVG uploads.
Do I need different formats for retina screens?
Not different formats — different sizes. Serve 2× dimensions for high-density screens via srcset, and let the format (ideally WebP/AVIF) keep the bytes in check.
Does Google rank pages by image format?
Not directly — Google ranks the outcome. Image weight drives Largest Contentful Paint, and Core Web Vitals feed rankings, so a lighter format improves SEO through speed rather than through the file extension itself.
Are GIFs still acceptable for Mobile Apps?
Only out of habit. GIF caps at 256 colors and balloons in size: a 5-second animation easily reaches 5-10 MB; the same clip as animated WebP is a fraction of that Animated WebP delivers the same clip dramatically lighter, and every current browser plays it.
How many formats should one Mobile Apps project use?
Usually three: a modern format for delivery, a universal fallback, and SVG for vector assets. More than that and the upload rules stop being memorable, which is when mistakes creep back in.
Is it worth re-converting an old image library?
Run the arithmetic on one folder first: convert a sample, multiply the saving by the library size. Libraries behind high-traffic pages almost always justify it; archives nobody serves can stay as they are.
Do stock photos need converting before upload?
Often yes — stock sites deliver maximum-quality JPEGs sized for print, not for pages. Resize to display dimensions and convert to your delivery format, and a 12 MB download becomes a 200 KB asset.
Mini glossary
Alpha channel. The per-pixel transparency layer. Formats without one flatten transparent areas, usually onto white.
Lossy / lossless. Whether compression discards data permanently or packs it reversibly. The single most consequential word on any format's spec sheet.
Bit depth. How many shades each color channel can hold; higher depth means smoother gradients and bigger files.
Encoding. The act of writing pixels into a format's structure. Slow encoders (AVIF) trade time for smaller output.
Artifacts. Visible compression damage — blockiness, halos around edges — produced by aggressive lossy settings or repeated re-saves.
Color profile. Metadata describing which exact colors the numbers mean. Mismatched profiles are behind most "the colors changed" complaints.
Container. A file wrapper that can hold image data plus extras — depth maps, multiple frames — as HEIC does.
Rasterize. Converting vector shapes into fixed pixels; the one-way step that costs a logo its infinite sharpness.
Start small: convert one page's images this week, measure the load time before and after, and let the result decide how far you roll it out.
Written by Giovanni Picaro, a web developer who has been building image tools and optimizing sites since 2019. Sources: MDN image format reference and Google web.dev. Last reviewed: 2026.