AVIF, WebP, JPEG, PNG or SVG? A Practical Web Image Decision Guide

• Choose by content type and required features, not a universal winner.
• Use picture for format alternatives and srcset/sizes for dimensional alternatives.
• Treat untrusted SVG as active content crossing a security boundary.

The short decision guide

Use SVG for logos, icons, diagrams, and illustrations that are genuinely vector-based. For photographs and other raster imagery, test AVIF and WebP as modern delivery options while retaining a fallback when your audience or pipeline requires one. JPEG remains a dependable photographic fallback. PNG remains useful when you need lossless raster reproduction or transparency, especially for screenshots and UI graphics where sharp edges matter.

That is the practical answer. The rest of the guide explains where each rule bends.

Start with raster versus vector

JPEG, PNG, WebP, and AVIF are raster formats: they store an image as pixels. A raster image has intrinsic pixel dimensions, so a small source enlarged too far becomes soft or blocky. SVG is vector: it describes shapes, paths, fills, and text in XML. Those instructions can be rendered cleanly at many sizes.

That distinction should come before codec comparisons. A logo built from simple paths is usually a natural SVG candidate. A photograph contains continuous detail that would be impractical to recreate as vector paths, so it normally belongs in a raster format.

Practical comparison

AVIF: capable, but make the workflow earn it

AVIF supports both lossy and lossless encoding, an alpha channel, higher color depths, and multi-image content. Those capabilities make it a credible delivery format for photographs and complex raster artwork, including images that need transparency.

The reason to choose AVIF should not be a copied claim that it is always a fixed percentage smaller. Results depend on the source, encoder, settings, target quality, metadata, and the visual tolerance of the page. Create representative derivatives, compare them at the sizes people will actually see, and retain the settings so the result can be reproduced.

Delivery is part of the decision. If a required browser, email client, CMS transformation, social-card service, or image proxy cannot reliably process your AVIF files, supply another source through <picture> or choose a simpler primary format. Encoding time and tooling also matter in high-volume publishing. A format that saves bytes but makes editorial production fragile is not automatically the better system.

WebP: a practical general-purpose raster option

WebP supports lossy and lossless images, transparency, and animation. That combination lets one delivery format cover many jobs that historically required separate JPEG, PNG, and GIF outputs.

For a typical site, WebP can be a pragmatic default derivative for article photography, card thumbnails, and raster illustrations. “Default derivative” is the important phrase: keep your original editable file or high-quality master. A delivery asset is not a substitute for a source archive.

WebP is still not a command to convert every file. A vector logo should usually remain vector. A screenshot should be checked for text-edge clarity. An existing JPEG may not benefit from repeated lossy transcoding. If a client requirement falls outside your verified support range, use a fallback rather than an unsupported compatibility claim.

JPEG: still useful for photographs

JPEG remains suitable for photographic still images and conventional fallbacks. Its long-established tool support and compatibility make it useful when reach and operational simplicity matter.

Its trade-offs are familiar. Standard JPEG is lossy, so aggressive compression can create ringing, blocking, or blurred detail. It does not provide an alpha channel, so it cannot represent the variable transparency used for assets that must sit over changing backgrounds.

None of that makes JPEG obsolete. A carefully encoded JPEG can be the right answer for an archive, a compatibility fallback, or a pipeline that does not yet handle newer formats safely. Avoid re-saving the same JPEG through repeated lossy generations; return to the best available master when producing a new derivative.

PNG: lossless raster detail and transparency

PNG uses lossless raster compression and supports transparency. It is a strong candidate for screenshots, UI fragments, line art, and graphics where preserving crisp edges or exact pixels matters.

PNG is not automatically the smallest file for every screenshot or flat illustration. Color count, dimensions, transparency, metadata, and the available encoders affect the result. WebP or AVIF in lossless mode may also deserve a test. Choose from visual requirements and measured outputs, not from a universal rule.

For ordinary photography, PNG often preserves more data than a web page needs. That does not make the format bad; it means the content and delivery goal do not line up.

SVG: the vector choice, with a trust boundary

SVG is usually the strongest fit for logos, icons, diagrams, charts, and illustrations composed of shapes. It can remain sharp across responsive layouts and high-density displays without creating a separate bitmap for every target size.

It is usually a poor fit for an ordinary photograph. Converting photographic detail into enormous collections of vector shapes can produce a complex document without gaining the practical advantages people expect from vector art.

SVG also needs two non-visual decisions. First, accessibility depends on context. An SVG used through <img> receives its text alternative from the image element’s alt. An inline SVG that conveys information needs an accessible name and, for a complex diagram, an adjacent explanation may be more useful than trying to put everything in one label.

Second, distinguish trusted artwork from untrusted uploads. SVG is XML and can contain active or externally referenced content in some contexts. Do not accept a file merely because its extension or user-supplied MIME type says image/svg+xml. For user uploads, use an explicit allowlist, inspect and sanitize content with a maintained SVG-aware process, store files outside executable application paths where practical, serve them with deliberate headers, and decide which embedding modes your product permits. Rasterizing an untrusted upload to a known-safe derivative is another option. A logo exported by your own design team and an arbitrary SVG uploaded by a stranger do not belong on the same trust path.

Use <picture> for format alternatives

The <picture> element lets you offer format alternatives while keeping an <img> fallback. The browser evaluates the <source> elements and can skip a type it does not support.

<picture>
  <source srcset="/images/harbor.avif" type="image/avif">
  <source srcset="/images/harbor.webp" type="image/webp">
  <img
    src="/images/harbor.jpg"
    width="1600"
    height="900"
    alt="Fishing boats moored in a harbor at sunrise"
    decoding="async">
</picture>

Put the preferred candidates first and keep the conventional fallback in src. The filenames and declared MIME types should agree. The width and height attributes give the browser an aspect ratio it can reserve before the image finishes downloading; CSS can still make the image fluid.

Do not add loading="lazy" mechanically to a primary image that is likely to become the page’s Largest Contentful Paint element. Lazy loading delays discovery until layout confirms proximity to the viewport. It can be appropriate for images farther down the page, but the page position and measured behavior should drive that choice.

Add srcset and sizes for responsive raster delivery

Format selection answers “which encoding can this client use?” Responsive selection answers “which pixel dimensions fit this layout?” They can work together.

<img
  src="/images/dashboard-960.png"
  srcset="/images/dashboard-480.png 480w,
          /images/dashboard-960.png 960w,
          /images/dashboard-1440.png 1440w"
  sizes="(max-width: 700px) 100vw, 700px"
  width="1440"
  height="900"
  loading="lazy"
  decoding="async"
  alt="Analytics dashboard showing weekly sign-ups by channel">

The width descriptors state each candidate’s intrinsic width. The sizes value describes the expected rendered slot: full viewport width up to 700 pixels, then a 700-pixel content column. That value must match the real CSS closely enough to help the browser choose. Here loading="lazy" is reasonable only because the example represents an offscreen content image, not the page’s primary above-the-fold image.

Write alt text for the image’s job

Alt text is not a caption, filename, or SEO keyword bucket. For an informative image, describe the essential information or function in the context of the page. The harbor example identifies the subject and setting. The dashboard example identifies the information the screenshot represents.

If an image is purely decorative and adds no information, use an empty alternative: alt="". That tells assistive technology it can skip the image. Do not omit alt and hope a screen reader guesses your intent.

Google’s image guidance also warns against stuffing alt with keywords. That aligns with the accessibility goal: write for the person who needs the image’s meaning, not for a list of search phrases.

A repeatable format-selection workflow

1. Classify the source. Is it a photograph, screenshot, UI element, simple illustration, diagram, logo, or animation? 2. Decide raster or vector. Preserve genuine vector art as SVG when the delivery context is trusted. Keep photographs raster. 3. List required features. Record transparency, animation, color depth, exact-pixel needs, editing requirements, and client constraints. 4. Choose candidate derivatives. For raster photography, that might be AVIF and WebP plus JPEG fallback. For a crisp screenshot, compare PNG with lossless modern options. 5. Export from a master. Do not build a new lossy derivative from an already degraded derivative when the master exists. 6. Compare representative outputs. Review normal display sizes, high-density screens where relevant, dark and light backgrounds for transparency, and difficult details such as hair, gradients, and small text. 7. Design delivery. Use <picture> for format alternatives and srcset/sizes for dimensional alternatives. Keep the fallback src. 8. Add dimensions and accessibility. Set accurate intrinsic width and height; write contextual alt, or alt="" for decoration. 9. Validate the actual path. Confirm MIME type, HTTP status, decoding, natural dimensions, layout stability, and mobile overflow.

1. Keep the decision reproducible. Save encoder versions and settings, source provenance, output hashes, and a rollback-capable master.

Common mistakes

• Declaring AVIF, WebP, or any other format the universal winner.
• Converting a vector logo to raster for every placement.
• Using PNG for all photographs because “lossless” sounds automatically better.
• Calling JPEG obsolete when it still meets a real compatibility or workflow need.
• Serving a new format without checking the CMS, CDN, browser range, social preview, and fallback.
• Using srcset candidates whose width descriptors do not match the files.
• Writing sizes that disagrees with the CSS layout.
• Lazy-loading the likely LCP image.
• Omitting dimensions and allowing the page to shift as images arrive.
• Stuffing alt with search phrases, or describing decorative flourishes that should be skipped.
• Treating an uploaded SVG as safe because the extension looks like an image.

FAQ

Should every site use AVIF now?

Not automatically. AVIF is a capable option, but the decision belongs to your audience, image pipeline, quality review, and fallback plan. Test representative content and the services that transform or consume it.

Is WebP a safe single default?

It can be a practical general-purpose raster derivative, but “single default” may ignore vector assets, exact-pixel screenshots, editable masters, or a required legacy client. Use it where the verified delivery requirements fit.

Is JPEG obsolete?

No. JPEG remains useful for photographic stills, conventional fallbacks, archives, and simple workflows. Its lack of alpha and lossy behavior are limitations to manage, not proof that it has no place.

When should I use PNG instead of SVG?

Use PNG when the content is fundamentally raster or when the target system cannot safely or reliably handle SVG. Use SVG when the artwork is genuinely vector and the trust and accessibility requirements are addressed.

Do modern formats remove the need for responsive images?

No. Encoding format and displayed dimensions are separate choices. A large AVIF can still be wasteful in a narrow slot. Use responsive candidates when one raster size does not fit every layout.

Final recommendation

Build a small decision system rather than a format religion. Keep SVG for trusted vector art. For photographic and complex raster delivery, evaluate AVIF and WebP from a high-quality master, retain JPEG when compatibility or simplicity calls for it, and use PNG when lossless raster detail or transparency is the real requirement. Then make the HTML complete: a real fallback, responsive candidates where useful, accurate dimensions, contextual alt text, and loading behavior based on the image’s position.

The correct choice is the one your team can validate, reproduce, and deliver to the clients that matter—without inventing a universal benchmark.

Sources and further reading

• MDN: Image file type and format guide
• MDN: The picture element
• MDN: The img element
• MDN: Using responsive images in HTML
• W3C WAI: Images Tutorial
• Google Search Central: Image SEO best practices
• web.dev: Optimize Largest Contentful Paint
• OWASP: File Upload Cheat Sheet