The Right Image Format for Every Web Use Case

They leave when the hero photo takes 2.4 seconds to paint. The right image format for every common web use case is simple: PNG for UI screenshots and transparency, JPG for photos without alpha, WebP for broad browser support with strong ratios, and AVIF when you want maximum compression on modern stacks.

I measure drop-off at the image paint, not at the checkout. A product gallery that ships 1.8 MB of unoptimized JPGs will lose people before they read a single feature line. At Atlas Photo we treat format choice as a conversion decision: smaller files, sharper detail, fewer abandoned sessions.

When should I use PNG on the web?

PNG is the lossless raster format you reach for when edges, text, and transparency matter more than file size. Use PNG for UI screenshots, logos with hard edges, icons that sit over variable backgrounds, and any asset that needs a true alpha channel.

PNG compression is lossless. That means every pixel survives the encode. A 1440px-wide dashboard screenshot with crisp type stays crisp. JPEG would smear the anti-aliased letters and introduce block noise around the chrome. On a pricing page, that noise looks cheap and it costs trust.

Transparency is the other hard rule. If the image must blend over a colored hero, a gradient card, or a dark mode surface, PNG (or a modern format with alpha) is required. JPG has no alpha. You cannot fake it cleanly with a white matte if the background color changes.

Typical PNG sizes for web UI still run heavy. A full-bleed 1920×1080 screenshot can land between 400 KB and 1.5 MB even after tools like pngquant or oxipng. That is fine for one critical diagram. It is wrong for a long scroll of lifestyle photography. Rule of thumb I use in audits: if the asset has soft gradients and no transparency, leave PNG.

In funnel tests I have run, replacing a 1.1 MB PNG product mock with a 180 KB WebP (same visual sharpness for that asset type) cut LCP by roughly 0.6–0.9 seconds on mid-range mobile. People stayed past the fold more often.

When is JPG still the right choice?

JPG (JPEG) is a lossy format built for continuous-tone photos without transparency. Camera images, lifestyle shots, blog heroes, and team portraits still convert well to JPG when you do not need alpha and you need universal decode support.

Quality settings matter more than the container name. At quality 75–85, most product photos keep detail in fabric, skin, and wood grain while staying far smaller than a PNG of the same pixel dimensions. Drop below 60 on busy scenes and you get ringing around high-contrast edges. Push above 90 and you often pay double the bytes for gains nobody notices on a phone screen.

JPG wins in three practical cases:

• You must support very old browsers or email clients that still choke on WebP or AVIF (see email clients)
• Your CMS or CDN pipeline only re-encodes to JPG today and a format migration is out of scope this sprint
• You are shipping progressive JPEGs as a temporary bridge while you wire multi-format delivery

Average e-commerce product shots at 1200px on the long edge often land between 80 KB and 250 KB as well-tuned JPG. That range is a usable baseline when you are still measuring before you adopt WebP everywhere.

Why choose WebP for most product pages?

WebP is a modern image format that supports both lossy and lossless modes plus alpha. For most product and marketing pages in 2026, WebP is the default delivery format because the size wins are real and browser support is effectively universal on current desktop and mobile engines.

Google’s long-running guidance on web.dev still holds in practice: lossy WebP often lands 25–35% smaller than comparable JPG at similar visual quality. Lossless WebP can undercut PNG on many UI assets while keeping sharp edges. Alpha works, so you can replace a large transparent PNG badge with a much smaller WebP without inventing a matte.

I default WebP for:

• Product photography on category and detail pages
• Blog and landing heroes when the background is a photo, not a transparent overlay
• Marketing carousels where every 100 KB multiplies across five slides
• Transparent logos and badges that were previously PNG

Encode at quality 75–80 for lossy WebP on photos, then spot-check hair, type overlays, and fine patterns. If a thumbnail looks muddy, bump quality before you jump formats. One aside while you read this: I am also measuring whether this post’s hero loads under 150 KB on a cold mobile cache, because every article is a funnel too.

When does AVIF win on compression?

AVIF is an image format based on the AV1 codec. It is the current king of still-image compression for photographic content when your stack can serve it and your audience is on recent browsers. The tradeoff is encode time and slightly more complex fallbacks.

On photo-heavy assets, AVIF routinely beats WebP by another 20–50% in file size at comparable visual quality, depending on content and encoder. A 160 KB WebP hero can become a 90–120 KB AVIF without a visible hit on a phone. That gap compounds on multi-image PLPs where ten products fight for the network.

AVIF is the right pick when:

• You already generate responsive srcset variants in a build or CDN step
• Encode cost is paid once at upload, not on every request on a weak origin
• You care about LCP on 4G and mid-tier Android more than you care about saving five minutes of pipeline work
• You can ship a WebP or JPG fallback for the long tail of older clients

Check current engine support on Can I use before you make AVIF the only URL. Support is strong on modern Chromium, Firefox, and Safari generations, which covers the bulk of commercial traffic. The residual risk is older WebViews and locked-down enterprise browsers. Fallbacks fix that cleanly.

Encode cost is the operational catch. AVIF can take several times longer than WebP to produce at high quality. Batch at ingest. Do not re-encode on the fly for every thumbnail request unless your edge already owns that job (see AVIF can take several times longer than WebP).

How do PNG, JPG, WebP, and AVIF compare?

Here is the decision map I use when an operator asks which format wins for a given asset class. The right image format for every common web use case depends on transparency, photo vs UI content, and how modern your delivery stack is.

Format	Best for	Alpha	Typical size vs JPG	Browser reality
PNG	UI screenshots, hard edges, logos needing lossless	Yes	Often 3–10× larger on photos	Universal
JPG	Photos without transparency, email, legacy CMS	No	Baseline	Universal
WebP	Default product and marketing images	Yes	~25–35% smaller lossy	Near-universal on current browsers
AVIF	Maximum compression on modern stacks	Yes	Often ~50% smaller than JPG	Strong on modern engines; use fallbacks

Quick assignment rules:

• UI chrome, docs screenshots, pixel-perfect diagrams: PNG or lossless WebP
• Photos with no transparency and no modern pipeline: JPG
• Photos and most marketing assets with a normal CDN: WebP first
• High-traffic product grids where every KB is revenue: AVIF + WebP fallback
• Transparent overlays on photos: WebP or AVIF with alpha; PNG only if the pipeline cannot emit those

How should I serve formats with fallbacks?

Serving multiple formats is a delivery problem, not a design problem. The browser should receive the best file it can decode without a second round trip that fails.

Use the HTML picture element with ordered sources: AVIF first if you generate it, then WebP, then a JPG or PNG fallback that matches the content type. Keep the same art direction across sources unless you intentionally crop differently per breakpoint. Pair that with srcset and sizes so a 390px phone does not download a 2400px master.

On the CDN side, many teams enable automatic format negotiation from a single origin object. That works when Accept headers are respected and cache keys include the negotiated format. If you self-host, pre-generate three variants at upload and store them beside the original. Measure TTFB and cache hit rate after you ship. A clever format chain that misses cache on every device class will erase the compression win (see cache hit rate).

Target budgets I use for conversion-critical pages:

• Above-the-fold hero: under 150–200 KB on mobile
• Product main image: under 100–150 KB at the displayed width
• Thumbnail grids: under 20–40 KB each
• UI screenshot with text: prefer sharpness over size, but still re-export if you are over 300 KB at display size

If you are already past those numbers, format choice alone will not save a 4000px-wide original that never got resized. Resize to the largest rendered width first. Then choose the format. Then tune quality. That order avoids “we switched to AVIF and nothing moved” postmortems.

What mistakes still kill image performance?

Teams waste weeks debating AVIF quality flags while shipping the same three errors. First, they keep uploading camera originals at 4000–6000px and rely on CSS to “scale them down.” The browser still downloads the heavy file. Second, they use PNG for full-bleed lifestyle photos because a designer exported from Figma that way. Third, they forget lazy-loading for below-the-fold galleries, so five 300 KB images compete with the hero for bandwidth on first paint.

Fix those, then re-test LCP and conversion. On merchandising sites I have audited, cleaning width and format together often frees 40–70% of image weight before any redesign. That is enough to move add-to-cart rate when the previous experience felt sticky on mobile.

For teams building catalog and portfolio experiences, the workflow at Atlas Photo starts from the same map: pick the format for the job, generate the right widths, and keep transparency only where the layout needs it.

Open your heaviest landing page in DevTools, sort the network panel by size, and re-export the top three images using the format map above before you touch copy or layout.

---

What is the difference between WebP and AVIF?

WebP is a widely supported modern format with strong size gains over JPG and PNG. AVIF is newer and usually compresses photographic images even further, often another 20–50% smaller than WebP, at the cost of slower encodes and the need for a fallback on older clients.

Does JPG support transparent backgrounds?

JPG does not support transparency. If you need a see-through background, use PNG, WebP, or AVIF with an alpha channel.

Should every site switch fully to AVIF now?

No. Ship AVIF where encode pipelines and fallbacks already exist, and keep WebP as the reliable middle layer. Full AVIF-only delivery still leaves edge cases on older browsers and some embedded WebViews.

---

Find any asset in seconds. Atlas Photo is digital asset management for creative and brand teams, with early-access founder pricing for the first users. Get early access