DEV Community

Ashish Kumar
Ashish Kumar

Posted on

A Developer's Guide to Image Formats: JPG, PNG, WebP, AVIF, and HEIC

#productivity #performance #webdev #frontend

You're checking in 200 product photos. Should they be JPG? PNG? WebP? AVIF? Whatever the designer dragged in?

This is the question every developer ducks until performance reviews force the conversation. The honest answer is "it depends" — but the dependencies are concrete and learnable, and once you know them you stop wasting bandwidth on the wrong format.

This is a practical guide to the five formats you'll actually touch (JPG, PNG, WebP, AVIF, HEIC), plus a quick note on SVG and GIF. File sizes, when each wins, browser support, the conversion gotchas.

The decision tree

Before the deep dive, here's the rough mental model:

You have... Use...
A photograph (smooth gradients, lots of color) JPG, or WebP/AVIF if you can serve them
A screenshot, diagram, logo, or any image with hard edges PNG, or WebP/AVIF
Something that needs transparency PNG, or WebP/AVIF
An image that needs to scale to any size (icons, logos) SVG
A short looping animation WebP, MP4, or GIF as last resort
A photo from an iPhone HEIC arriving, JPG/WebP serving

That table covers 90% of cases. The other 10% is in the details.

JPG (JPEG) — the workhorse

Released 1992. Lossy compression tuned for photographs. Discards information humans don't notice — fine color variation in skies, tiny details in busy areas — and keeps file sizes small.

Strengths: universal support, excellent compression for photos, predictable behavior.

Weaknesses: lossy (re-saving degrades quality), no transparency, terrible for text and hard edges (compression artifacts make text look fuzzy).

Practical compression: for photos served on the web, quality 75–85 is the sweet spot. Below 70 starts looking obviously compressed; above 90 wastes bytes for invisible quality. Most image tools default to quality 90 — too high.

Gotcha: don't open a JPG, edit it, and re-save it as JPG repeatedly. Each save is another lossy compression pass; after five or six rounds the photo looks visibly degraded. If you're going to edit, save as PNG or TIFF mid-flow, then export to JPG once at the end.

PNG — the lossless backbone

Released 1996. Lossless compression, supports transparency, supports indexed color (palette-based) for tiny file sizes on simple graphics.

Strengths: transparency, lossless (can re-save infinitely), great for screenshots and graphics.

Weaknesses: much larger than JPG for photos. A 1MB photo as JPG might be 4MB as PNG.

The two PNG modes:

  • PNG-24: 16 million colors plus alpha transparency. What most tools save by default. Best for photos and complex graphics.
  • PNG-8: 256-color palette plus optional 1-bit transparency. What every old icon and screenshot used. Tiny file sizes for simple images.

If you've got a logo with three colors on it, PNG-8 is often 10× smaller than PNG-24 with no visible difference. Most modern tools auto-pick or let you choose; older ones default to PNG-24 and waste space.

When to use PNG over WebP/AVIF: when you need maximum compatibility (very old browsers, email clients, system-level previews on outdated OSes) or when you need lossless preservation for further editing.

WebP — Google's modern compromise

Released 2010, mainstream-ready by 2018. Both lossy and lossless modes, supports transparency, supports animation. Compresses 25–35% smaller than JPG at equivalent quality, 26% smaller than PNG losslessly.

Strengths: smaller files than JPG/PNG with comparable quality, transparency, animation, supported in every modern browser.

Weaknesses: the encoder is slower than JPG. Not supported in some legacy email clients or very old browsers (IE11, but we don't care). Some image-editing tools still don't open WebP natively.

Browser support: universal in modern browsers as of 2020. Safari was last to adopt it (Safari 14, 2020). If you can require Safari 14+, you can serve WebP unconditionally.

Practical note: WebP wins biggest on photos that have lots of smooth gradients. On hard-edged graphics (UI screenshots, line art) the savings over PNG are smaller — sometimes WebP is even larger. Test both before assuming WebP is smaller.

AVIF — the newest, smallest, slowest to encode

Based on the AV1 video codec. Released 2019, broadly supported by 2023. Compresses 30–50% smaller than JPG at similar quality, often 20% smaller than WebP.

Strengths: the smallest file size of any common format. Supports transparency, HDR, and wide color gamuts.

Weaknesses: slow to encode (5–10× slower than JPG), some image tools and CDNs still don't support it, decoding on low-end devices can be slow.

Browser support: Chrome 85+, Firefox 93+, Safari 16.1+. As of 2026, support is broad enough to ship — but always serve a JPG/WebP fallback for the long tail.

When to use: when you have build-time image optimization, you're shipping a lot of photos, and bandwidth or LCP scores matter. For one-off images uploaded by users at runtime, the encoding cost may not be worth it.

HEIC — the iPhone format your build pipeline doesn't speak

HEIC (High-Efficiency Image Container) is what iPhones save photos as by default since iOS 11 (2017). Compresses about 50% smaller than JPG at equivalent quality. Apple ecosystem treats it as native; everything else treats it as a problem.

Strengths: dramatic file-size savings, supports HDR, transparency, and burst sequences.

Weaknesses: patent-encumbered, no native browser support (Safari supports it system-wide but not in <img> tags), most non-Apple tools can't open it.

The practical issue: users upload HEICs to your web app from iPhones, and your backend can't process them. They show up as broken images, fail to thumbnail, error out in image-processing pipelines.

Solutions:

  • Server-side conversion to JPG or WebP on upload. Libraries like heif-convert or sharp (with libheif) handle this.
  • Client-side conversion before upload, using a HEIC-to-JPG tool. There's a browser-based HEIC to JPG converter at imagetools.renderlog.in if you want to test what your users are uploading. It runs entirely in the browser, so the photo never leaves the device.
  • Configure iPhone to save as JPG. Settings → Camera → Formats → Most Compatible. Most users don't know this exists.

SVG and GIF — quick mentions

SVG (Scalable Vector Graphics). Vector format, scales infinitely, tiny file sizes for icons and logos. Use for: icons, logos, simple illustrations. Don't use for: photographs (impossible) or anything with realistic shading.

GIF. Released 1987. Use for: nothing, ideally. Supports animation but at terrible compression — a 5-second GIF is often 10× larger than the same content as an MP4 or WebP. The only legitimate modern use is as a fallback for environments that don't support video tags.

Serving multiple formats

The browser-friendly way to serve modern formats with fallbacks is the <picture> element:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero image" width="1200" height="600">
</picture>
Enter fullscreen mode Exit fullscreen mode

Browsers pick the first format they support. If all three are present, modern browsers get AVIF, slightly older ones get WebP, anything else falls back to JPG.

The build pipeline to generate all three is straightforward with tools like sharp, squoosh, or vite-imagetools. If you're not generating multiple formats automatically, you're leaving 20–40% of bandwidth on the floor.

Common conversions and where they bite

A few real-world conversion paths and what to watch for:

  • JPG → WebP: safe and lossless if you keep quality high; verify color space (some tools accidentally drop sRGB profiles).
  • PNG → JPG: loses transparency. Anything that was transparent becomes opaque white (or black, depending on the tool).
  • HEIC → JPG: lossy; once converted, you can't get the HEIC quality back.
  • WebP → PNG: lossless if the source was lossless WebP; lossy WebP converted to PNG looks fine but doesn't recover detail.
  • AVIF → anything: generally works, but very high-quality AVIF can produce huge PNGs.

If you're doing one-off conversions while building, imagetools.renderlog.in has dedicated converters for the common pairs — WebP to JPG, HEIC to JPG, JPG to WebP, PNG to WebP, and an image compressor for size targets. All client-side.

TL;DR

Format When to use Notes
JPG Photos, broad compatibility Quality 75–85 sweet spot; don't re-save repeatedly
PNG Screenshots, transparency, graphics PNG-8 for simple images is often 10× smaller
WebP Modern web replacement for JPG/PNG 25–35% smaller, universal support since 2020
AVIF Photos with build-time optimization Smallest, slowest to encode, ship with fallback
HEIC Receiving from iPhones Convert to JPG/WebP on upload
SVG Vector graphics Icons, logos, never photos
GIF Legacy fallback only Use WebP or video instead

Set your build pipeline to generate AVIF + WebP + JPG, serve them through <picture>, and forget about format until the next refactor. Your users save bandwidth, you save Core Web Vitals points, everyone wins.

If this was useful, I've also built a handful of other free, browser-based tools — no signup, no uploads, everything runs client-side:

Top comments (0)