The core mental model

The concepts that matter most are file formats, containers, and codecs. In everyday image work, JPEG, PNG, GIF, WebP, AVIF, SVG, and JPEG XL are discussed as image formats. Video needs a more explicit distinction.

Saying “MP4 versus AV1” mixes two layers. An MP4 container can carry video encoded with H.264 or, in compatible workflows, AV1. The compact analogy is:

Container = box. Codec = the method used to compress what is inside.

Images: from the old model to the modern one

The older rule of thumb was JPEG for photographs, PNG for transparent or lossless graphics, and GIF for animation. That model remains useful context, but it is no longer a complete delivery strategy.

SVG

If the source artwork is vector-based—logos, icons, diagrams, or simple illustrations—SVG is often the first format to consider. The browser renders geometry rather than enlarging a fixed pixel grid, so the result stays sharp at any resolution. WebP and AVIF do not automatically replace PNG for every logo; for suitable artwork, SVG is usually the better replacement.

AVIF

AVIF stands for AV1 Image File Format. It uses AV1 image coding and can provide excellent compression while supporting transparency, high bit depth, wide-gamut and HDR-oriented color, and both lossy and lossless modes. For photographic raster imagery in a modern delivery pipeline, AVIF is a strong default candidate.

WebP

WebP was developed by Google as an efficient web image format. It supports lossy and lossless compression, transparency, and animation. Its mature browser and tooling ecosystem makes it a useful modern format and a practical fallback when AVIF is not the right fit.

JPEG, PNG, and GIF

JPEG and PNG are not obsolete. JPEG remains a highly compatible photographic format. PNG remains valuable when exact lossless pixel reproduction matters, including some screenshots, graphics, and source assets. The difference today is that photographic or transparent content does not force either choice.

GIF is an image format whose multiple frames created the familiar looping animation. For new work, animated WebP, animated AVIF, APNG, or an actual <video> element will often be more efficient. Longer or photographic animation is usually a signal to treat the content as video.

A practical image strategy

Photographic content

AVIF → WebP → JPEG

Vector logos and icons

SVG

Exact lossless raster reproduction

PNG, lossless WebP, or lossless AVIF, based on requirements and tooling

These variants do not always need to be made by hand. Frameworks, build pipelines, image CDNs, and optimization services can generate them from a high-quality source asset. Test visual quality against real content instead of assuming one format always wins.

Responsive images: srcset and sizes

Compression format is only one part of image performance. A 3000-pixel-wide AVIF is still wasteful when it is displayed at 400 CSS pixels.

<img
  src="/images/property-1200.jpg"
  srcset="
    /images/property-480.jpg 480w,
    /images/property-768.jpg 768w,
    /images/property-1200.jpg 1200w,
    /images/property-1600.jpg 1600w
  "
  sizes="
    (min-width: 1024px) 50vw,
    100vw
  "
  width="1600"
  height="900"
  alt="Landscaped property"
/>

• srcset lists image candidates and their intrinsic widths.
• sizes describes the image’s approximate layout width under different conditions.
• The browser combines those hints with the layout, device pixel ratio, zoom, and other conditions to choose a candidate.

There is no universal correct number of variants. A modest ladder of widths should cover the sizes the image really occupies. Let an automated pipeline produce that ladder when the project supports one.

What happens when the device rotates?

When viewport dimensions or layout conditions change—for example, from portrait to landscape—the browser can re-evaluate responsive image selection. That does not guarantee a second download: the current candidate, browser cache, updated resolution needs, and browser implementation all affect the result.

You provide candidates and layout information; the browser owns candidate selection.

Combining formats and responsive sizes

The <picture> element combines format negotiation with responsive candidates. The browser evaluates the sources and requests a suitable candidate; it does not download every listed format.

<picture>
  <source
    type="image/avif"
    srcset="
      /images/property-480.avif 480w,
      /images/property-768.avif 768w,
      /images/property-1200.avif 1200w,
      /images/property-1600.avif 1600w
    "
  />

  <source
    type="image/webp"
    srcset="
      /images/property-480.webp 480w,
      /images/property-768.webp 768w,
      /images/property-1200.webp 1200w,
      /images/property-1600.webp 1600w
    "
  />

  <img
    src="/images/property-1200.jpg"
    srcset="
      /images/property-480.jpg 480w,
      /images/property-768.jpg 768w,
      /images/property-1200.jpg 1200w,
      /images/property-1600.jpg 1600w
    "
    sizes="(min-width: 1024px) 50vw, 100vw"
    width="1600"
    height="900"
    alt="Landscaped property"
    loading="lazy"
  />
</picture>

Lazy loading

Native image lazy loading is a browser feature:

<img src="/photo.avif" loading="lazy" alt="…" />

This does not install a JavaScript scroll handler. The browser discovers the image, may defer its request while it is far from the viewport, and normally starts fetching before it literally crosses into view. The exact distance and timing are implementation details.

1. Browser parses the HTML and discovers the image.
2. The image is far from the viewport, so the browser may defer it.
3. The user approaches the image or the browser predicts it will soon be needed.
4. The browser requests the selected candidate, decodes it, and renders it.

Do not lazy-load everything

Images visible on initial load—especially the image responsible for Largest Contentful Paint—should generally load eagerly. For an important LCP image, fetchpriority="high" can be a useful hint when measurement shows it is needed. Below-the-fold images are the natural candidates for loading="lazy".

Supply intrinsic width and height whenever possible so the browser can reserve the correct aspect-ratio space before the image arrives, reducing layout shift.

Video

Keep codecs and containers separate

A .mp4 file is not synonymous with H.264, even though H.264 video with AAC audio in an MP4 container has long been a common web combination. Similarly, AV1 video is normally packaged in a container such as WebM or MP4, not delivered as a mysterious .av1 web video.

H.264

H.264, also called AVC, has been a web video workhorse for years. Its largest practical advantage is the broad playback ecosystem built around it. A common compatibility-oriented stack is:

MP4 container
H.264 video
AAC audio

AV1

AV1 was developed by the Alliance for Open Media. Its main benefit over older codecs is compression efficiency: comparable visual quality can generally be delivered with fewer bits, reducing bandwidth and storage. The tradeoff is more encoding work, and real playback capability depends on the browser, operating system, device, profile, and available hardware acceleration.

A practical video strategy

For ordinary self-hosted video, multiple sources can pair modern compression with a compatibility fallback:

<video controls preload="metadata" poster="/images/demo-poster.avif">
  <source
    src="/video/demo-av1.webm"
    type='video/webm; codecs="av01, opus"'
  />

  <source
    src="/video/demo-h264.mp4"
    type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'
  />

  Your browser does not support HTML video.
</video>

The precise comparison is WebM containing AV1 → MP4 containing H.264, not “AV1 → MP4.” In production, the codec strings must match the profiles and codecs actually encoded in each file.

Larger streaming systems eventually need more than a handful of static files. Adaptive streaming with HLS or DASH can offer multiple resolutions and bitrates so playback responds to network and device conditions.

What’s next?

JPEG XL

JPEG XL is worth following for progressive decoding, high bit depth, wide-gamut and HDR-oriented workflows, and efficient lossless recompression of existing JPEGs. Its browser adoption has changed over time and is not universal. As of this review, WebKit ships JPEG XL support in current Safari generations, but production use should still include a fallback through <picture> unless the audience is tightly controlled.

AV2

AV2 is AOMedia’s successor to AV1. Version 1.0 of the bitstream and decoding specification became a final deliverable on May 28, 2026. Its goal is another major step in compression efficiency and capability, but a finished specification does not make a codec an immediate production default.

Adoption also requires mature encoders and decoders, browser and operating-system integration, hardware acceleration, streaming infrastructure, tooling, and a large installed base. AV1 remains the modern production codec to understand today; AV2 is the next generation to watch.

Current rules of thumb

• Use SVG for suitable vector artwork.
• For photographs, prefer AVIF with WebP and/or JPEG fallbacks when compatibility requirements warrant them.
• Pair efficient formats with srcset and accurate sizes.
• Remember that srcset selects existing files; it does not generate them.
• Lazy-load below-the-fold media, not critical LCP content.
• Specify image dimensions so the browser can reserve layout space.
• Keep video codecs separate from their containers.
• Use MP4 with H.264/AAC when broad compatibility matters.
• Consider AV1 in WebM or MP4 for more efficient modern delivery, with an appropriate fallback.
• Watch JPEG XL and AV2 as their ecosystems evolve.

Efficient encoding + correct dimensions + intelligent loading + caching and delivery + browser-native selection