PNG, JPG, WebP and AVIF: Which Image Format for Which Job

Most advice about image formats is written as a ranking, with a winner at the top. That framing is wrong, and it is why people end up with 8 MB PNG screenshots and logos with smeared edges. The formats are not competing on a single axis. Each one is a set of decisions about what can safely be thrown away, and those decisions suit different pictures. Once you know what each format discards, the choice is usually obvious in a few seconds.

Lossless and lossy, and what lossy actually removes

A lossless format stores your image so that decoding it returns the exact pixel values you started with. It still compresses, but only by describing repetition more efficiently: a run of identical pixels, a row that is nearly the same as the row above it. Nothing is approximated. PNG works this way.

A lossy format compresses far harder by deciding that some of the information in the image is not worth the bytes. It is not deleting pixels at random. JPEG, for example, splits the image into small blocks and describes each block as a sum of frequency patterns using the discrete cosine transform, then stores the fine, high-frequency detail more coarsely than the broad shapes. Human vision is far more sensitive to differences in brightness than in colour, so lossy encoders also tend to store colour at lower resolution than brightness. What you lose is subtle texture and precise colour boundaries. What you keep is almost everything your eye was going to notice.

That trade is excellent for a photograph, where fine texture is noise anyway, and terrible for a screenshot of text, where the fine detail is the content.

JPG: built for photographs, and honest about it

JPG (the file extension for JPEG) is the format the entire photographic world runs on. Every camera writes it, every piece of software reads it, and for continuous-tone images it is still remarkably good for the bytes.

Its failure modes are recognisable once you know them. Around a hard edge — the boundary of black text on white, the outline of a logo — you get faint halos, sometimes called ringing or mosquito noise, because a sharp step is expensive to describe with smooth frequency patterns. In large flat areas such as a clear sky you can get visible blocking, where the 8×8 grid the encoder works on becomes faintly apparent as banding or squares. Push the quality setting down far enough and both become impossible to ignore.

JPG also loses a little every time you save it. Opening a JPG, making a small change and saving again means the encoder quantises pixels that were already quantised, on a block grid that may no longer line up with the original if you cropped or resized. The damage is cumulative and it cannot be undone. In practice most of it happens in the first few generations and when edits happen between saves. The habit worth forming: keep an original in a lossless format if the image will be edited repeatedly, and treat every JPG you export as a final delivery copy rather than a working file.

Finally, per MDN’s format reference, “JPEG does not support an alpha channel”. There is no transparency in a JPG, at all. Any transparent area has to become a solid colour on the way in.

PNG: exact pixels, real transparency, wrong tool for photos

PNG is lossless, supports full alpha transparency, and reproduces sharp edges perfectly. That makes it the right answer for screenshots, diagrams, UI exports, line art, pixel art, and anything containing text you expect to stay crisp.

It is the wrong answer for photographs, and the reason is structural rather than a matter of settings. PNG compresses by finding predictable structure — repeated colours, rows that resemble their neighbours. A photograph has almost no exact repetition; every pixel of sky is a slightly different value from the one beside it. There is very little for a lossless encoder to exploit, so the file stays large while a lossy encoder would produce something a fraction of the size that looks identical at normal viewing distance.

PNG has one capability the others mostly lack: it supports 16 bits per colour component as well as 8, along with greyscale and indexed-colour modes. Sixteen-bit PNG is rarely what you want for the web, but it matters if an image is an intermediate step in an editing pipeline where repeated adjustments would otherwise introduce banding.

WebP: two different codecs sharing one extension

WebP is best understood as two formats in one container. MDN describes it as supporting “lossy compression via predictive coding based on the VP8 video codec, and lossless compression that uses substitutions for repeating data”. Lossy WebP is a JPG replacement; lossless WebP is a PNG replacement. Both support transparency, and WebP also supports animation — which is why animated WebP turns up as a GIF replacement.

This is worth knowing because “convert to WebP” is ambiguous. This site’s converters encode lossy WebP. If you feed a screenshot to a lossy WebP encoder you will get a smaller file with softer text, not a lossless copy.

On size, Google’s own documentation states that “WebP lossless images are 26% smaller in size compared to PNGs” and that “WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index”. Those are the encoder author’s figures on their own test corpus, not a measurement we made, and your own images may land well outside that range. We have not run a benchmark and will not quote one as if we had.

Support is no longer a real constraint for the web: when we checked caniuse.com in July 2026 it reported roughly 96% of tracked global browser usage supporting WebP. Support outside browsers is patchier — some email clients and older desktop applications still will not open one.

AVIF: better compression, newer plumbing

AVIF comes from the AV1 video codec and is the most capable of the four on paper. MDN lists it as supporting lossy and lossless compression, alpha, animation, and 8-, 10- or 12-bit colour depth, which means it can carry high dynamic range material that JPG and WebP cannot. Browser support is broad: caniuse.com reported around 93% of tracked global usage for AVIF when we checked in July 2026, with Chrome, Edge, Firefox, Safari and Opera all shipping it.

The practical caveats are about tooling rather than browsers. AVIF encoding is computationally heavier than JPEG or WebP encoding, which matters when you are processing a large batch. Support in non-browser software — image viewers, older editors, email clients, some upload forms — still lags well behind support in browsers, so an AVIF file is a slightly riskier thing to email to someone than a JPG. And its advantage is smallest exactly where the alternatives are already strong: for a small, simple graphic, format overhead can dominate and AVIF may not win at all.

The decision, as a table

The print row is deliberately unhelpful because there is no honest general answer. Print requirements come from the printer’s equipment, and a browser-based tool cannot help with the part that usually matters: browsers work in RGB, so nothing on this site converts to CMYK. If you need a print-ready file, get the spec before you convert anything.

Transparency, animation and colour depth

The capability differences, drawn from MDN’s image format guide:

One caveat on the animation column: a format supporting animation and a given piece of software handling animated files are different questions. Plenty of converters, this site’s included, will process only the first frame.

Converting between them

The single most useful thing to understand is that conversion never restores information. Converting a heavily compressed JPG to PNG produces a lossless copy of the damaged pixels — the blocking and ringing are now preserved perfectly, in a larger file. Going from JPG to PNG is a way to stop further loss, not to undo loss already taken.

Which directions actually preserve everything:

• Lossless to lossless (PNG to lossless WebP, for instance) keeps the exact pixels.
• Anything to a lossy format takes a fresh generation of loss, including lossless-to-lossy, and including a second pass over an image that was already lossy.
• Lossy to lossless preserves what is left but recovers nothing.
• Anything to JPG also discards transparency, since JPG has no alpha channel. Transparent pixels have to be flattened onto some solid colour, and different tools choose differently.

Being specific about what this site does, since the point of these guides is to be checkable: the format converters here — Convert Image and the pair-specific pages like PNG to JPG, JPG to WebP and PNG to WebP — decode your file, draw it onto an HTML canvas and export it with the browser’s built-in encoder at a fixed quality of 0.92. There is no quality slider on those pages. Output is limited to PNG, JPEG and WebP; there is no AVIF export here, because these converters rely on the browser’s canvas export and MDN notes only that “browsers are required to support image/png; many will support additional formats including image/jpeg and image/webp”. The same page notes that if a requested format is unsupported, the browser silently exports PNG instead — so on an unusual browser a file named .webp could contain PNG data. Two file types take a different route in. HEIC files from iPhones bypass the canvas entirely, going through a dedicated decoder on the pages that accept them, Convert Image and HEIC to JPG. And SVG to PNG rasterises the SVG at whatever size the file declares, falling back to 1024×1024 if it declares none.

The image compressors are separate and do give you a quality control, but they also cap the longest edge at 4096 pixels, so a very large photo will come back downscaled as well as recompressed. If you want a smaller file at the original dimensions, converting to a more efficient format is usually the better lever than compressing harder.

None of these are the right tool for every job. If you need lossless WebP, AVIF output, 16-bit colour preserved through a conversion, CMYK, or animated frames kept intact, use a desktop encoder — cwebp, avifenc and ImageMagick all expose controls a canvas-based converter simply does not have. What a browser tool is genuinely good at is the common case: one image, a format you can name, and no desire to upload it anywhere.