How to Choose the Best Image Format for the Web

There is no single best image format for every website image. Use SVG for scalable geometric artwork such as logos and icons; AVIF or WebP for many photographs and raster graphics when their quality, file size, and browser coverage fit your audience; JPEG when broad compatibility for photographs matters; and PNG when lossless reproduction or transparency is important. Test the encoded result at the size it will appear, and use <picture> fallbacks when serving newer formats.

The right choice depends on what the image contains, whether it needs transparency or animation, which browsers your visitors use, and how much visual change is acceptable. This guide gives you a repeatable decision process and runnable HTML examples.

1. Choose by image content and job

Image or requirement	Good starting format	What to check
Logo, icon, diagram, chart, line art	SVG	It scales cleanly because it describes geometry. Do not use it as a general container for complex photographs. Keep meaningful text as accessible HTML text when possible.
Photograph or continuous-tone image	AVIF or WebP; JPEG fallback	Compare the visible detail and bytes at the actual display size. Lossy compression can introduce artifacts or change color.
Screenshot, small text, sharp edges, flat-color graphic	PNG or lossless WebP/AVIF	Lossy artifacts are easier to notice around text and edges. Inspect the actual export; PNG is a straightforward lossless option.
Transparency	PNG, WebP, or AVIF	JPEG has no alpha transparency. Compare newer formats against PNG for the particular image.
Animation	WebP, AVIF, or APNG	Check browser and workflow requirements. For many animations, video may be a better delivery choice. GIF is limited to 256 colors and can be larger than comparable video.
Broad compatibility requirement	JPEG or PNG fallback	Use a fallback in `<picture>` if you also offer newer formats.

These are starting points, not guaranteed winners. MDN and web.dev describe the capabilities and tradeoffs of these formats and the use of fallbacks. MDN’s image format guide and web.dev’s format guide provide further detail.

2. Compare lossy and lossless output

Lossy encoding reduces data by changing image information. It often works well for detailed photos, where small artifacts may be hard to notice. But the same changes can be obvious in high-contrast text, screenshots, thin lines, and flat-color artwork. Lossless encoding preserves the image information, though its file may be larger than a lossy version.

Do not choose a format by extension or a single quality preset. Export representative images in candidate formats, inspect them at their rendered dimensions, and compare visual quality against file size. Pay special attention to text, gradients, skin tones, edges, and transparency. web.dev recommends trying compression levels and examining the results; its image performance guide also covers image dimensions and responsive delivery.

Google’s WebP documentation publishes general comparisons: it says WebP lossless images are 26% smaller than PNG images, and lossy WebP images are 25–34% smaller than comparable JPEG images at equivalent SSIM quality. These are documentation figures, not a guarantee for your images; test a representative set. Google’s WebP documentation.

3. Deliver modern formats with a fallback

A plain <img> references one source. The <picture> element lets the browser select the first supported matching source, with the nested <img> acting as the fallback. Put AVIF and WebP sources before a compatible JPEG or PNG fallback:

<picture>
  <source type="image/avif" srcset="/images/landscape.avif">
  <source type="image/webp" srcset="/images/landscape.webp">
  <img
    src="/images/landscape.jpg"
    alt="Mountain lake at sunrise"
    width="1600"
    height="900"
  >
</picture>

Use the fallback format that matches the image and your compatibility needs: JPEG is suitable for many photographs; PNG is appropriate when you need lossless imagery or transparency. The browser can choose a supported source, but the files still need to exist at the referenced paths.

4. Provide responsive sizes and dimensions

Delivering a huge image to a small rendered slot wastes bytes; an image with too few pixels can look soft on a high-density display. Supply width candidates and describe the rendered slot with sizes so the browser can select an appropriate candidate. Include intrinsic width and height on the fallback image to reserve its aspect ratio.

<picture>
  <source
    type="image/avif"
    srcset="/images/team-640.avif 640w,
            /images/team-1280.avif 1280w"
    sizes="(max-width: 700px) 100vw, 700px"
  >
  <source
    type="image/webp"
    srcset="/images/team-640.webp 640w,
            /images/team-1280.webp 1280w"
    sizes="(max-width: 700px) 100vw, 700px"
  >
  <img
    src="/images/team-1280.jpg"
    srcset="/images/team-640.jpg 640w,
            /images/team-1280.jpg 1280w"
    sizes="(max-width: 700px) 100vw, 700px"
    alt="The team gathered outside the studio"
    width="1280"
    height="853"
  >
</picture>

The browser uses the declared source candidates and layout hints to select an image; it cannot make a missing or incorrectly sized candidate useful. Generate candidates from the same original, verify each path, and make the sizes expression reflect the actual layout. Responsive delivery and appropriate dimensions can reduce image bytes and may help Largest Contentful Paint when the image is the LCP candidate. web.dev’s LCP guidance.

5. A practical format selection workflow

Classify the visual. Use vector geometry for logos, icons, and diagrams. Treat photographs and screenshots as raster images.
List requirements. Does it need alpha transparency, animation, exact pixel fidelity, or wide browser coverage?
Choose candidates. For photos, compare AVIF and WebP with JPEG as needed. For transparent graphics or screenshots, compare PNG with lossless WebP or AVIF. Use SVG for scalable geometry.
Export at realistic dimensions. Include the largest rendered size and any responsive candidates your layout needs.
Inspect and measure. Compare bytes and visual quality side by side at actual display size, including details likely to reveal compression artifacts.
Implement fallback behavior. Use <picture> with typed sources when offering newer formats and a nested <img> fallback.
Check the deployed page. Confirm the browser loads the intended candidate, the fallback path works, and the image looks correct on the target viewport and display density.

Tools such as Squoosh and ImageOptim can help produce and compare exports; web.dev also describes image optimization services. Use whichever workflow lets you review quality and verify generated files.

6. Cost, performance, and reliability considerations

Measure bytes per image class. A format that wins for one photograph may lose for a screenshot or icon. Compare representative assets rather than extrapolating from one file.
Include delivery cost in the decision. Smaller files can reduce transferred bytes, but conversion, storage of multiple candidates, and cache behavior are operational concerns. The dossier provides no universal cost or benchmark figure.
Keep source assets. Retain a suitable high-quality original so you can regenerate variants if your layout or requirements change.
Make builds reproducible. Generate variants consistently and validate that referenced files are present. A modern-format source with a missing fallback is a delivery failure regardless of compression quality.
Check the audience’s browsers. Browser support changes; check current support for the formats and features you plan to rely on, particularly animation and newer formats. A fallback reduces dependence on a single source format.
Assess page impact. Image bytes and dimensions affect loading, but the actual effect depends on placement, network, caching, and the rest of the page. A smaller file alone does not guarantee a particular performance result.

7. Troubleshooting image format problems

Symptom	Likely cause	Fix
Image is broken in some browsers	A format or feature is unsupported, or a source URL is wrong.	Check current browser support and network requests. Add a valid JPEG or PNG fallback in the nested `<img>`.
New format appears ignored	The browser selected another supported source, a source type is wrong, or the candidate failed to load.	Inspect the rendered image’s current source and network panel. Confirm the MIME type, file path, and server response.
Text or edges look smeared	Lossy compression is too aggressive for sharp detail.	Raise quality or switch to PNG or a lossless WebP/AVIF export; compare at the final display size.
Transparent image has a solid background	JPEG was used, or alpha was discarded during export.	Use PNG, WebP, or AVIF with transparency and confirm the encoder preserves alpha.
Image looks soft on a high-density screen	The supplied raster dimensions are too small for its rendered size and pixel density.	Generate larger responsive candidates and use a suitable `srcset`.
Page downloads more bytes than expected	Oversized source, unsuitable compression, or the browser is selecting a larger candidate than intended.	Inspect actual requests, correct rendered dimensions and `sizes`, then compare encoding output.
Layout shifts while image loads	The browser does not know the image’s intrinsic aspect ratio in advance.	Set accurate `width` and `height` on the `<img>` or reserve the correct aspect ratio in layout.
Animation does not play as expected	Format or browser/workflow support differs, or export settings removed animation.	Verify the delivered file is animated and test target browsers; consider video for longer or numerous animations.

8. Or skip the browser setup

If you need a screenshot of a web page to inspect image rendering, ScreenshotNeo is a website screenshot API and MCP server. Its one-call API can return a screenshot in PNG, JPEG, or WebP, or a PDF. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners are accepted and removed before capture; known newsletter popups and chat widgets are removed too.
Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing; response headers identify page verdict and billing status.
An MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf.
1,000 screenshots per month are free with no card; paid plans start at $5 for 3,000.

9. Frequently asked questions

Should I use WebP or AVIF?

Compare both on representative images at acceptable visual quality and check browser coverage for your audience. Either can be a strong raster option, but neither is automatically best for every asset.

When should I use PNG instead of JPEG?

Use PNG when lossless fidelity or transparency is required, or when lossy artifacts are unacceptable for the image. JPEG has no transparency and is a broadly compatible lossy choice for many photographs.

Is SVG suitable for photographs?

SVG is designed for scalable geometry such as logos, icons, and diagrams. Complex photo scenes are generally better represented as raster pixels.

Does a smaller image file always make a page faster?

Smaller bytes can help image loading, but page performance also depends on dimensions, placement, network, caching, and other page resources. Measure the deployed page rather than assuming a format change guarantees a result.