The format decision used to be simple: JPEG for photos, PNG for anything with sharp edges or transparency. In 2026 you also have WebP and AVIF, both widely supported, both usually smaller, and both still the wrong choice in more situations than the blog posts admit.

I built jpg.now because I kept doing the same conversions for client sites, CMS uploads, and "please send a JPG" requests, and I am the site's maker, so I will be explicit about that. Here is the decision guide I would keep next to the deploy checklist.

The four formats, without the mythology

JPEG (JPG). Lossy, universal, and still the default interchange format for photographs. It has no alpha channel, so a transparent source will pick up a background. At sensible quality settings it is hard to beat for "this has to open everywhere"; push it too low and you get 8×8 blocking. Progressive JPEG helps on a slow connection.

PNG. Lossless, with a real alpha channel. Use it for screenshots, UI, logos, diagrams, and anything where a wrong pixel is a bug — not for photographs, which get large fast. If you need lossless and smaller files, look at lossless WebP or AVIF.

WebP. Lossy and lossless modes, plus alpha and animation. Lossy WebP is typically smaller than a comparable JPEG; lossless WebP is often smaller than PNG. Chrome, Edge, Firefox, and Safari all support it (full Safari support from 16; 14–15 was partial). Internet Explorer never got it.

AVIF. Also lossy and lossless, with alpha, high bit depth, and HDR. At a given visual quality it is often the smallest of the four, but it does not progressively render and encoding is heavier. Chrome has had it since 85, Firefox since 93, Safari since 16.4 (16.1–16.3 were partial), and Edge since 121. As of November 2026, Can I Use puts WebP at about 97% of global usage and AVIF just under that.

JPEG XL exists, but I would not ship it as the only source. A short rule that holds up:

  • Photos for the web: AVIF first, WebP second, JPEG as the compatible file.
  • Sharp graphics or UI with transparency: lossless WebP or PNG, with PNG as the fallback.
  • A single file that must survive email, a print lab, a CMS uploader, or a client laptop: JPEG, or PNG if you need transparency.

Browser support is not the same as "it will work"

Current browsers are not the problem. The long tail is. Coverage is high enough to ship WebP and AVIF as primary sources, but gaps remain: older iOS Safari (WebP needs 14+; AVIF needs 16+), older Android WebViews, Internet Explorer, and non-browser surfaces such as email clients, desktop Office apps, some upload forms, and stale WebViews.

The HTML should still carry a fallback. The <picture> element is widely supported:

<picture> <source srcset="photo.avif" type="image/avif"> <source srcset="photo.webp" type="image/webp"> <img src="photo.jpg" alt="Product on a workbench" width="1600" height="1200" loading="lazy" decoding="async"> </picture>

The browser walks the <source> elements in order and uses the first type it understands. AVIF-capable clients never download the JPEG. Everyone else gets the <img> file, which should be a real, reasonably compressed JPEG — not a placeholder or a 4000-pixel original.

Four rules that keep this from going wrong:

  1. Encode every derivative from the master, not from each other. An AVIF made from a WebP made from a JPEG stacks generation loss.
  2. Keep the same pixel dimensions across the sources for one picture. A 1600-pixel AVIF next to a 4000-pixel JPEG makes the fallback the heavy path.
  3. Send the right MIME type (image/avif, image/webp, image/jpeg). A server that serves WebP as image/png defeats the type hint.
  4. Confirm in the Network panel which file was actually fetched, with its type and size.

Set width and height on the <img> so the layout does not jump. If you use srcset and sizes, apply the same breakpoints to each format, not only to the JPEG.

When JPG still wins

I still export a JPEG more often than the format wars would suggest.

The file has to leave the website. Upload forms, printers, photo labs, and "please send the images as JPG" threads are not going to learn AVIF this year. A single .jpg almost never bounces.

The surface does not honor <picture>. Many email clients ignore your sources and show the <img> anyway — or fail if that src is a WebP. For newsletters, JPEG (or a carefully tested PNG) is the safe asset.

You need a preview that paints early. Progressive JPEG can show a usable version while the rest of the file arrives. AVIF does not. On a large hero over a slow link, that difference is visible.

The image will be re-saved by someone else. Clients crop in Preview, marketers drop files into slides, and some CDNs recompress whatever you give them. Keep the master and mint a fresh JPEG, rather than handing over an AVIF the next tool silently transcodes.

None of this means "ship only JPEG in 2026." It means keep a JPEG (or PNG) in the chain, and do not treat a modern format as a complete replacement for interchange.

Batch-converting without making the files worse

Most of the damage I see is not the choice of format. It is the pipeline.

  • Work from the highest-quality master you have: the camera RAW, or a 16-bit TIFF or PNG, not a JPEG that has already been through email.
  • Resize first, then compress. A 4000-pixel photo served at 800 CSS pixels wastes bandwidth no matter how clever the encoder is. Pick the largest display size you need (and a 2× version if necessary), then encode.
  • Choose quality by looking at the image at 1×. For WebP and JPEG, 75–85 is a reasonable start for photographs; go higher for heroes with text, lower for thumbnails. AVIF can often sit a little lower for the same visual result, but check.
  • Strip location EXIF from public web assets. Keep an embedded sRGB profile if color accuracy matters.
  • Do not re-encode a lossy file just to change the extension. JPEG and JPG are the same format; renaming is enough if that is all you need.
  • Name files so the format is obvious (hero.avif, hero.webp, hero.jpg) and keep the masters outside the public folder.

If you are converting a handful of images, or a messy mix of HEIC, PNGs, and RAWs, a browser converter is enough. jpg.now is the one I built for that job. You drop one or more files, choose the output format, and set quality, dimensions, and whether metadata is kept. Guests can use it with no account — 10 conversions a day, in batches of up to 10, with no watermark on standard conversions. Uploads travel over HTTPS, conversions run on the server, and guest files are deleted within 24 hours. It also handles iPhone HEIC to JPG, RAW files (CR2, CR3, NEF, ARW, DNG, RAF, and others) to a shareable JPG, and merging a folder of images into one PDF.

For a large, repeatable pipeline, use a script or your image CDN so every encode starts from the master with the same settings. The format choice only pays off if the files you ship are the ones you meant to ship.