If you've ever right-clicked "Save Image As" and stared at a format dropdown, you've run into this problem: JPG, PNG, WebP, and now AVIF all claim to be the "right" choice, and the honest answer is it depends on what's in the image and where it's going. Here's the practical version, without the marketing spin.

The short version

	JPG	PNG	WebP	AVIF
Compression	Lossy	Lossless	Both	Both
Transparency	No	Yes	Yes	Yes
Animation	No	Yes (APNG)	Yes	Yes
Typical photo size	Baseline	Much larger	25–35% smaller	40–50% smaller
Encoding speed	Fast	Fast	Fast	Slow
Accepted everywhere	Yes	Yes	Mostly	Not yet

Every one of those rows has a "but". The rest of this covers them.

JPG: the default for photos

JPG (or JPEG) uses lossy compression — it throws away image detail your eye is unlikely to notice, in exchange for a much smaller file. That trade-off is exactly right for photographs, where there's already a ton of natural detail and noise to spare.

The mechanism explains most of JPG's behaviour. The encoder chops the image into 8×8 pixel blocks and describes each one as a sum of wave patterns, then discards the finest waves first — because that's the detail eyes are worst at noticing. Smooth areas need very few waves to describe, so they compress enormously. Sharp edges need many, so they compress badly.

That single fact predicts every JPG artifact you've ever seen. Text and logos develop a faint halo, because a hard black-to-white edge is the hardest thing to describe with a handful of waves. Skies and gradients develop visible steps, because the encoder is approximating a subtle ramp with too few of them.

Best for: photos, anything with gradients, complex colour, or texture.
Weak spot: sharp edges and flat colours (text, logos, UI screenshots) get blurry "artifacts" around the edges.
No transparency support. Save a transparent image as JPG and the background becomes white.

One more JPG-specific trap: generation loss. Every time you open a JPG and save it again, the encoder throws away detail from an image that has already had detail thrown away. Do that half a dozen times and the degradation becomes obvious. Always re-export from the original when you can, rather than repeatedly re-saving the same JPG.

PNG: the default for graphics

PNG is lossless — it never throws away detail, which means a PNG always looks pixel-perfect compared to its source. The cost is file size: PNG has to work much harder to shrink an image without losing anything, so on a real photo it usually ends up larger than an equivalent JPG.

PNG compresses by finding repetition — long runs of identical pixels, rows that resemble the row above. A screenshot of a settings panel is mostly flat grey and repeated shapes, so it shrinks dramatically. A photograph of leaves has almost no exact repetition anywhere, so there's very little for PNG to work with, and the file stays huge.

Best for: logos, icons, screenshots, illustrations, anything with flat colour or text, and anything that needs a transparent background.
Weak spot: photos. The quality slider has limited effect on plain PNG output, since there's no lossy step that actually removes detail; you're mostly re-encoding the same pixels more efficiently.

Worth knowing: PNG has two common flavours. PNG-24 stores full colour and is what most tools export. PNG-8 stores a palette of at most 256 colours and can be several times smaller — genuinely useful for flat-colour logos and simple icons, and terrible for anything with gradients, which turn into visible bands.

WebP: the modern middle ground

WebP supports both modes: lossy (like JPG, but typically 25–35% smaller at the same visual quality) and lossless (like PNG, with meaningfully better compression on most images). It also supports transparency and animation. For most day-to-day use, WebP is simply a smaller version of whichever format you'd otherwise pick.

The lossy side is built on VP8, a video codec from 2010, and it improves on JPG mainly by predicting each block from its neighbours before encoding the difference — so a smooth region costs almost nothing to store. WebP's lossless mode is a separate design entirely, and it's genuinely strong: for screenshots and flat graphics it routinely beats PNG by 20% or more while staying pixel-identical.

Best for: almost everything, if the platform you're uploading to supports it.
Weak spot: a handful of older tools, some print workflows, and a few platforms still don't accept it. That's the most common reason people end up needing to convert a WebP file back into JPG or PNG.

AVIF: the newest option, and the most efficient

AVIF is newer than WebP and, in terms of pure compression, usually beats it — often 20–30% smaller than an equivalent WebP at the same visual quality, with both lossy and lossless modes.

It's built on AV1, a video codec finished a decade after VP8, and it inherits far better tools for predicting and encoding blocks of pixels. It also supports higher bit depth, which is why AVIF handles skies and shadows with less banding than either JPG or WebP at a comparable size.

Every modern browser can already display AVIF — decode support has been universal for a while. Creating one used to be the catch: the only browsers with a native AVIF encoder are Chrome and Edge, since Firefox and Safari never shipped one. img-compress sidesteps that by running its own AVIF encoder compiled to WebAssembly instead of depending on the browser's, so converting to AVIF works the same regardless of which browser you're using.

Best for: squeezing out the smallest possible file, especially for photos — the larger the image, the more it tends to beat WebP by.
Weak spot: slow to produce, and its container overhead only pays for itself above a certain size. Encoding the same flat icon at a fixed quality, we measured WebP smaller at 40 pixels a side and below, with AVIF ahead from 48 px up — and plain PNG smaller than both at those sizes. Favicons and tiny icons are not where AVIF pays off.

The things that aren't about size

Format choice is usually framed as a compression contest, but three other properties decide it just as often.

Transparency. JPG has none. If an image has a transparent background and you convert it to JPG, that background gets filled with white — a one-way trip, and easily the most common unpleasant surprise when converting. PNG, WebP and AVIF all handle it.

Animation. GIF is still the universally accepted format, and also by far the worst: 256 colours and enormous files. Animated WebP and AVIF are dramatically smaller and look far better. APNG exists and works, but sits awkwardly between the two.

Metadata. JPG, WebP and AVIF can all carry EXIF — camera model, timestamps, and often GPS coordinates. If you're posting a photo publicly, that's worth thinking about. Re-encoding through a converter typically drops most of it, which is usually a feature rather than a loss.

What about HEIC?

If your images come off an iPhone, they're probably HEIC rather than any of the four above. HEIC compresses about as well as AVIF, but it's effectively an Apple-ecosystem format: support elsewhere is patchy, and plenty of upload forms reject it outright. The practical answer is almost always to convert it to JPG before sending it anywhere. We covered the Windows-specific side of this in how to open HEIC files on Windows.

Support in 2026: viewing is solved, uploading isn't

For displaying images, this question is settled. Every browser still receiving updates handles all four formats. If your only concern is that a visitor can see the image, WebP and AVIF carry no real risk.

The friction has moved somewhere else: upload forms. Government portals, job application systems, older content management systems, print shops, and a long tail of desktop software still expect JPG or PNG and will reject anything else — often with an unhelpful error. That's why "convert WebP back to JPG" is such a common need, despite WebP being universally viewable. Browser support and platform acceptance are two different things, and only the first one is finished.

Four mistakes that cost the most bytes

Saving photos as PNG. The single most expensive mistake. A photo that would be 400 KB as a JPG can easily be 3 MB as a PNG, with no visible benefit whatsoever.
Saving text screenshots as JPG. The exact opposite error. Lossy compression smears the hard edges of letters, so you get a file that's both blurry and larger than the PNG would have been.
Re-saving the same JPG repeatedly. Generation loss compounds silently. Go back to the original.
Compressing without resizing. If a 4000-pixel-wide photo is going somewhere that displays it at 800, scaling it down beats any quality setting. Compression is the second step, not a substitute for the first.

So which one do you actually need?

It's a photo, and you want the smallest reasonable file → AVIF for the smallest possible result, or WebP if you'd rather trade a little compression for a faster conversion.
It's a logo, icon, or screenshot with text → PNG, or WebP lossless if the platform supports it.
You need it to work absolutely everywhere, no exceptions → JPG for photos, PNG for graphics.
You have a WebP or AVIF file and the place you're uploading to rejects it → convert it to JPG or PNG.
It's a tiny icon → PNG. The modern formats have nothing to offer at that size.

Converting between any of these, without the guesswork

Once you know which format you actually need, img-compress covers all four: JPG, PNG, WebP, and AVIF, converting in either direction and running entirely on your device, so nothing gets uploaded whether it's a single photo or a folder of them. If you already know you want JPG↔PNG specifically, the dedicated JPG to PNG and PNG to JPG converters skip straight to that. It also reads HEIC/HEIF files on Safari, so an iPhone photo can go straight to whichever format the situation actually calls for. If you're weighing the two modern formats specifically, AVIF vs WebP goes deeper on that comparison.

WebP vs JPG vs PNG vs AVIF: Which to Use?