Choosing the Right Image Format for a Website

Decide by image type

• Photographs and other continuous-tone pictures: JPEG as the dependable choice, WebP or AVIF where you want smaller files and can provide a fallback.
• Logos, icons and diagrams that must stay sharp at any size: SVG when a vector version exists; otherwise PNG.
• Screenshots, UI captures and line art with text: PNG, or lossless WebP if your tooling supports it. Lossy compression leaves colored fringes around sharp text.
• Images that need transparency: PNG, WebP or AVIF. JPEG has no transparency at all.
• Animation: GIF works everywhere but is inefficient; animated WebP or AVIF are the usual replacements where supported.

These rules match the guidance in MDN's image format guide, which recommends lossless formats for screenshots, diagrams and line art, SVG for icons and drawings that must scale, and WebP or AVIF for raster images generally, with a JPEG or PNG fallback because those two newer formats lack the historical browser support of the older ones.

What MDN and web.dev actually say

Rather than a ranking, the two reference sources offer cautions worth keeping in mind.

web.dev's Learn Images course says PNG should be considered mainly for simple artwork that needs semi-transparency, such as a logo with a drop shadow, and that it is a poor fit for photographs because the files become very large. It describes JPEG as the most common web format, notes that the quality value runs from 0 to 100 but is interpreted differently by different tools, so "75" will not look identical everywhere, and adds that faint artifacts are easy to miss while browsing but become glaringly obvious if compression is taken too far. For AVIF, it records the browser timeline (Chrome and Opera in 2020, Firefox in 2021, Safari in 2022) and warns that a browser that cannot decode a format renders nothing, which leaves broken images.

The practical reading is that newer formats are a gain when you provide a fallback, and a risk when you do not. MDN shows the standard pattern: a picture element listing several sources from most to least preferred, followed by an img element with a widely supported file, so each browser takes the first source it understands. For photos that means, for example, AVIF, then WebP, then a JPEG in the img element.

Measured on synthetic test pictures

To see how much the type of content changes the result, I encoded two synthetic 1920 by 1080 pictures with the Pillow imaging library. The first imitates an interface screenshot: flat colors, thin outlines and text rows. The second imitates a photo: smooth color gradients, soft blobs and a little sensor-like noise. They are not real screenshots or photographs, and real files will vary, but the pattern is instructive. Sizes are in bytes.

Test picture	PNG	JPEG q90	WebP q90	WebP q80
UI-like, flat colors and text	119,602	263,809	85,412	67,334
Photo-like, gradients and noise	4,036,108	448,583	474,550	161,380

Three things stand out. On the flat picture, PNG is more than twice as small as JPEG (263,809 / 119,602 is 2.2), reversing the common belief that JPEG is always the compact option. On the photo-like picture, PNG is about nine times larger than JPEG. And at the same nominal quality of 90, WebP was slightly larger than JPEG on the noisy picture, because quality numbers are not comparable between encoders, in line with web.dev's warning that tools interpret a value such as 75 differently. Compare formats by looking at file size and appearance together, never by the slider value alone.

Pixel dimensions usually outweigh the format

A format change might save a modest share of the bytes; a dimension change can save most of them. Suppose a photo is displayed in a column 800 CSS pixels wide. A screen with a pixel ratio of 2 can use at most 1600 pixels of width. A 4032 pixel original contains (4032 / 1600) squared, about 6.35 times as many pixels as that, and the extra pixels cost bytes without ever being visible.

The standard solution is the srcset and sizes attributes, which let you publish several widths and let the browser pick; web.dev's responsive images module explains the syntax. Without them, at least resize the image to the largest size it will be shown at. The converter's maximum size menu can cap the longest side at anything from 3840 to 640 pixels and never enlarges small images.

What the sizes add up to on a page

Per-file numbers look small until you multiply them. Take a page with six photo-like images, each the size of the synthetic test above. As PNG, that is 6 x 4,036,108 = 24,216,648 bytes, about 24 MB. As JPEG at quality 90 it is 6 x 448,583 = 2,691,498 bytes, about 2.7 MB. On a connection delivering 5 megabits per second, the first takes roughly 39 seconds to transfer and the second roughly 4. Real connections fluctuate and browsers fetch in parallel, so the exact times will differ, but the ratio between them will not.

This is what web.dev means when its course lists PNG as unsuitable for photographs: the format is not broken, the content simply does not suit it. When a page feels slow, the largest images are the first place to look, and a format or dimension fix there removes more weight than any other change.

Three typical pages and what to do

A blog hero photo. Export a JPEG at about the display width times the pixel ratio. If your pipeline can also produce WebP or AVIF, add them behind a picture element; otherwise the JPEG alone is fine. Avoid PNG for this; in the test above it was nine times the size for no visible gain.

A product shot with a white background. A photograph, so JPEG. If the page background is white, you do not need transparency at all. If the page is not white and you do need a cutout, use PNG or WebP, or decide on a fixed background color as described in the background color article.

A logo with a soft shadow. SVG if you have it, PNG if you do not. WebP also handles semi-transparency, which is why the two are often compared in the PNG and WebP comparison.

Where this converter fits in the workflow

The converter can write JPEG, PNG, WebP, BMP and ICO files. AVIF and SVG are not among the outputs, and its WebP is lossy, so lossless WebP or AVIF files need other tooling. It does cover the common cases: turning a PNG photo into a far smaller JPEG, creating WebP copies (see converting images to WebP), and shrinking the longest side to a practical web size. For a favicon, the ICO guide covers the 256 pixel limit.