Support <picture> and <source> in next/image

[ascorbic]

Currently next/image only supports next-gen images such as WebP via Accept header, because there's no way to handle fallback for old browsers. This means that image hosts or CDNs that only support changing format based on the URL cannot safely deliver next-gen formats. It also makes it harder to cache images.

The standards-compliant way to do this is to generate a <picture> tag with a <source> tag for each supported format.

My proposal would be to keep the default behavior the same: generate an <img> tag and use content negotiation in the server for next-gen formats. However we would add a "formats" key to the image config, which could include next gen image formats. The supproted values for these would depend on the handler, and would be just WEBP by default. If this array was present, then the <img> tag would be exactly the same, with auto format, but it would be wrapped with a <picture> tag and would include a <source> element for each requested type, with type attribute containing the mimetype. This would pass an extra "format" option to the handler function when generating the URLs. The default handler would generate these URLs with an additional f parameter, which the image server would use to choose a format to generate.

This would be fully backwards-compatible, as the <img> tag would be unchanged and would still use the auto format, and the <picture> tag would only be included if the formats array was included in the config. It would fix issues such as #25136 too.

I have worked on a proof-of-concept and would be willing to develop this into a PR if this proposal is approved.

PR: #25683

[leerob]

Hey! Thanks for opening this. The team is currently busy preparing for Next.js Conf in a week but will provide a response here after 😁

[ascorbic]

Thanks! Related PR here #25683

[ascorbic]

I've updated the PR with the latest version, so it plays nicely with static sources etc.

[leerob]

Okay, conference over! Following up here.

There is a related discussion around optimizing images for high-density displays (#26065), which would use the picture tag.

The team is interested in exploring this, in combination with this RFC, and @atcastle will be leading that work.

[egeriis]

Did anything come off this @leerob? Could you x-post RFC, if it exists? Thank you :)

[NorbertHS]

Hello,

I'm fully supportive of this initiative.

I would like to add some additional information regarding this task on the top of managing optimized picture size based on device and density:

• as media attribute of source tag element is basically a way to put any media query, personally I use it for managing dark/light mode for instance:

          <picture>
            <source srcSet="/vercel_dark.svg" media="prefers-color-scheme: dark" />
            <img src="/vercel.svg" alt="Vercel Logo" />
          </picture>

• as well by extension, based on the size of the device, sometime the content of the picture is not appropriate and I'm willing to load a different picture, not the same one downcale

So it can be great if we can add a kind of specific custom rules and let next/image manage the others default one.

Like:

<Image src="/vercel.svg">
  <source srcSet="/vercel_dark.svg" media="prefers-color-scheme: dark" />
</Image>

[brianlovin]

+1 to this – would love to any kind of abstraction to pass through media queries + alternative source strings (in my case, I'm trying to do what is mentioned above, which is to show one image in dark mode and another in light mode).

[leerob]

Agreed. That would be very helpful 😄

[styfle]

This is a great use case!

I'm curious if you have tried out next-themes for managing dark/light mode? (readme shows a next/image example)

This works with the "system" theme (aka prefers-color-scheme) but also allow the user to manually select a theme.

For arbitrary media queries, you can use window.matchMedia() to dynamically set the src prop.

Update: also checkout fresnel for nicer API.

[brianlovin]

Thanks for the link @styfle – I'll try plugging in next-themes for the src switching, makes sense.

[NorbertHS]

Thank you for the suggestion @styfle about next-themes.
To be honest, I'm not a huge fan of this approach for several reasons 😅 :

• the main one is I use NextJS is the ability to deliver powerful applications which are compliant with the high standard of SEO. Using this solution with next/image will bring an async request of the correct image to display, will download 2 images or load a dummy image and will increase the LCP and CLS time.
• the second reason is more a personal choice, but when a browser offers native features which allow us, as developers, to write less code and ship lighter JavaScript code to final user, I prefer so far to rely on them, especially when they are well supported by Browsers. I love the approach of next/images because despite the fact that it doesn't use directly the srcSet approach but rely on resolution based on browser capabilities sent with the request's headers, we don't need to write additional boilerplate code, neither to ship lots of code to final user and it works pretty fine with the basic requirements for SEO.

So if possible, I would rather prefer a solution which will rely as much as possible on native features for all the reasons mentioned above than to a solution which will require a client-side resolution after mount.

Thank you 🙂

[Perni1984]

@atcastle are there any news on supporting picture within next/image or can we help there somehow?

[tx0c]

make some noise/pressure/help there #25683

[leerob]

We're exploring options for where to take next/image based on community feedback and will have something to share in the next few months.

[trickydisco78]

any updates on this?

[gavinthomas-valtech]

[AlexandreBourdeaudhui]

Hello! Any update on this ? I would like to introduce img with art-direction in my project, but it's not possible (correctly), actually, with next/image. We can't use the internal optimization with the actuel behavior and workaround w/ picture and source element.

[mkamalkayani]

Any updates on this issue?

[sayinmehmet47]

any update ?

[leerob]

Will be sharing an update soon, making some progress here on direction. Thank you for your patience 🙏

[agsmartwolf]

It has been four months. I'm looking forward to updates))))

[lachlanjc]

The team is exploring in a few weeks ☺️ https://staging.bsky.app/profile/styfle.dev/post/3jue5bcxodn2x

[agsmartwolf]

What is an alternative for implementing this behaviour using next/image component right now?

[cat-michael-gwynne]

I'm using lh3.googleusercontent and those URLs accept a load of image options: https://github.com/votemike/lh3-googleusercontent-url-builder/blob/main/index.d.ts
I would love to use next/image but instead have to use a custom made <picture> component to support both webp and jpg.

[NorbertHS]

Maybe I'm wrong, but if you use a custom loader, you will be able to customise your URL and it will be still optimise by NextJS and so will be served as WEBP/AVIF based on browser capabilities.

Or is Next/Image optimiser disabled when using this approach?

[cat-michael-gwynne]

I can't see any documentation on how NextJS lets custom loaders know which file formats a browser supports.
If that is the case, I'd love a link to the documentation. Or even a link to the part of code that does that and I can write the documentation.

[faradaytrs]

Well i guess they just see Accept header in http request @cat-michael-gwynne

[evgeniy-skakun]

any update ?

[Zhumatic]

Found people tested this code to be effective, not sure:

const MyImage = () => {
    return (
      <picture>
        <source srcSet={MyDarkImage.src} media="(prefers-color-scheme: dark)" />
        <Image
            src={MyLightImage}
            alt="My image"
            width={300}
            height={300}
        />
      </picture>
  );
};

source:
https://stackoverflow.com/questions/71313889/how-can-i-present-a-different-next-image-based-on-the-users-preferred-color-sch

[NorbertHS]

Looks interesting for some cases.
I assume the dark image will not be responsive and optimised as the NextJS Optimiser will be focus only on the Light version.

[sti-web]

I used that example to have jpeg and webp images.
Works for me.
An img srcset was properly generated.

[AlexandreBourdeaudhui]

@sti-web Do you use Next/Image for jpeg/webp images ? Because actually, if i'm using the code below, i have the original image (jpeg), without optimization (either webp or avif) :(.

[sti-web]

@sti-web Do you use Next/Image for jpeg/webp images ? Because actually, if i'm using the code below, i have the original image (jpeg), without optimization (either webp or avif) :(.

I have prepared webp with cloudinary, so I always have jpeg and webp

  <picture>
    <source
      srcset={`/1.webp`}
      type="image/webp"
    />
    <source
      srcset={`/1.jpeg`}
      type="image/jpeg"
    />
    <Image
      width={200}
      height={200}
      alt="Your alt here"
      srcSet="/1.webp, /1.jpeg"
      src="1.jpeg"
      className="image image--active"
    />
  </picture>

OUTPUT:
<picture><source srcset="/1.webp" type="image/webp"><source srcset="/1.jpg" type="image/jpeg"><img alt="Your alt here" srcset="/_next/image?url=%2F1.jpg&amp;w=256&amp;q=75 1x, /_next/image?url=%2F1.jpg&amp;w=640&amp;q=75 2x" loading="lazy" width="200" height="200" decoding="async" data-nimg="1" class="image image--active" src="/_next/image?url=%2F1.jpg&amp;w=640&amp;q=75" style="color: transparent;"></picture>
As you see Nextjs create 1x and 2x srcsets

[AlexandreBourdeaudhui]

I have prepared webp with cloudinary, so I always have jpeg and webp

Yes. Next/Image does not generate/optimize a webp image in your case, you need to prepare... If i'm using your snippet, Chrome wants to use the webP image, but it is not generated by Next/image.

<picture>
  <source srcset="/image_x.webp" type="image/webp" />
  <source srcset="/image_x.png" type="image/png" />
  <Image
    alt="Your alt here"
    srcSet="/image_x.webp, /image_x.png"
    src="/image_x.png"
    height={200}
    width={200}
  />
</picture>

Another example, if you need to use a different image with a "responsive" condition (with the media property), the 2nd image is not optimized/updated by Next/Image.

<picture>
  <source
    srcset="/image_123.webp"
    type="image/webp"
    media="(min-width: 960px)"
  />
  <Image
    alt="Image X alt"
    src="/image_x.png"
    srcSet="/image_x.webp, /image_123.webp"
    height={250}
    width={250}
  />
</picture>

(Sandbox here)

[xd-hearst]

yeah, we can always build our own. Next image is not much more than a wrapper of native image.

[kelenakamura]

someone had posted this as an alternative in another thread similar to this - https://github.com/humaans/next-img

[NorbertHS]

I'm not sure about the benefit of this package...
Resizing + format optimisation is something that native next/image is doing pretty well.
It doesn't cover the ability to change source based on media query (not only size, but theme, motion, ...) which offer the native picture tag.

[hutchida]

@leerob How's the art direction upgrade to the Next/Image going?

[1Ghasthunter1]

Any update on this? Still seems to be very high demand.

[undefineq]

Any updates on this issue?

[leerob]

Update: We have extracted the core logic from next/image into a new unstable_getImgProps() function.

This allows usage outside of <Image>, such as:

1. Working with background-image or image-set
2. Working with canvas context.drawImage() or simply new Image()
3. Working with <picture> media queries to implement Art Direction or Light/Dark Mode images

Example

import { unstable_getImgProps as getImgProps } from 'next/image'

export default function Page() {
  const common = { alt: 'Hero', width: 800, height: 400 }
  const { props: { srcSet: dark } } = getImgProps({ ...common, src: '/dark.png' })
  const { props: { srcSet: light, ...rest } } = getImgProps({ ...common, src: '/light.png' })

  return (<picture>
  <source media="(prefers-color-scheme: dark)" srcSet={dark} />
  <source media="(prefers-color-scheme: light)" srcSet={light} />
  <img {...rest} />
</picture>)
}

PR: #51205

[styfle]

you can half the file quality, as Jake Archibald suggests. As far as I can tell (with my limited knowledge), this is not done automatically

Its not clear what automatically would look like. Should the quality passed in represent the 2x case because the developer is working on a 2x display when running next dev and then the 1x version is double the quality of what the developer passed in? This is why unstable_getImgProps() doesn't make these decisions automatically - its for these advanced cases.

[kurtextrem]

Next.js already does that. See

Pretty exciting, thank you for making me aware of this!

As far as I can tell, this is only done when not using the sizes prop we've been talking about in the previous comments, do I read this correct?
I created a demo to check it: https://codesandbox.io/p/sandbox/quirky-paper-qkzjh4 (I again want to emphasize I'm not a Next expert, so if I did a mistake, I'm sorry in advance, I'm not trying to waste anyone's time.)

What I'd expect: for each size, we have a cap at 2x and all browsers pick whatever fits their screen best taking DPR into account (ignoring quality for now).
Let's do the density maths for a 360px width & 3x DPR device (e.g. latest iPhones have a DPR of 3x):

• Firefox & Safari pick the next largest density to the DPR:
  • 256w / 360px = 0.71
  • 384w / 360px = 1.06
  • 640w / 360px = 1.77
  • 750w / 360px = 2.08
  • 828w / 360px = 2.3
  • 1080w / 360px = 3 <-- 1080w is picked by them
  • (1200w / 360px = 3.3)
• Chromium: see the function at the bottom of the codesandbox -> 1080w is picked

So the actual output of the srcset leads to:

• browsers loading a heavier image. Of course, we could say this is a browser vendor issue (e.g. Chromium has plans to autocap), but we, from the author side, also have options to fix this (by switching to <picture> in such scenarios, or by using the technique I describe in my article)
• If we further take into account that instead of loading quality 75% for the 1080w image, we could reduce the quality to <= 50% for the 768px breakpoint, I think this makes a good argument for taking action...

...maybe this is do-able via the new unstable_getImgProp function? Not entirely sure, but:

Its not clear what automatically would look like

What if we give it a shot? Maybe not as "default enabled" feature, but it helps to have such mode in general, as having to manually implement such things in that case means you have quite some engineering effort and getting this right is hard. And hard quite often means it's deprioritized (in my experience).

Coming back to your thoughts, I'll write down some quick ideas regarding your points, and maybe we can come up with a better solution together?

• We could add e.g. something like qualityPerSize, similar to the advanced imageSizes and deviceSizes, where you could map the quality to the generated widths (vws)
• Add a prop that makes devs aware of what is going on (e.g. autoDPRQuality), plus if we document what it does, devs do less easily get confused when inspecting the source

If you have a slack or so, I'd also be open to brain storm there so we don't pollute the thread. Just let me know whatever crosses your mind, I'm happy to contribute if wanted.

[djfarly]

Not sure which props getImgProps actually needs to create the srcset but this component works for me and decouples the source element nicely:

import { ImageProps, unstable_getImgProps as getImgProps } from 'next/image';
import { forwardRef } from 'react';

type SourceProps = Omit<JSX.IntrinsicElements['source'], 'srcSet' | 'src'> &
  Pick<ImageProps, 'src' | 'loader' | 'unoptimized' | 'quality'>;

export const Source = forwardRef<HTMLSourceElement, SourceProps>(function Source(
  { src, loader, unoptimized, quality, ...rest },
  ref
) {
  const {
    props: { srcSet }
  } = getImgProps({ src, loader, unoptimized, quality, fill: true, alt: '' });

  return <source {...rest} srcSet={srcSet} ref={ref} />;
});

use as such:

import Image from 'next/image';
import { Source } from '@/components/Source';

function MyPage() {
  return (
    <picture>
      <Source media="(orientation: portrait)" src="/portrait.png" />
      <Image
        src="/landscape.png"
        layout="fill"
        className="whatever"
        sizes="100vw"
        alt="My Cool Image"
      />
    </picture>
  );
}

Hope this helps someone and I'm not missing something 🎉

[vicasas]

@leerob

I have been waiting for this functionality for a long time! Thank you!!.

However, I'm afraid it doesn't work as I expected or I still don't understand the configuration.

We need to support images of different sizes for mobile and desktop in an ecommerce. So we use this:

import { unstable_getImgProps as getImgProps } from 'next/image'

export default function Picture() {
  const common = { alt: 'Hero' }
  const {
    props: { ...rest },
  } = getImgProps({
    ...common,
    width: 600,
    height: 587,
    src: 'https://assets-prdcom/header-1-mb.jpg',
  })
  const {
    props: { srcSet: desk },
  } = getImgProps({
    ...common,
    width: 1920,
    height: 650,
    src: 'https://assets-prd.com/header-1-desk.jpg',
  })

  return (
    <picture>
      <source media="(min-width: 600px)" srcSet={desk} />
      <img {...rest} />
    </picture>
  )
}

But we did not get the expected results. The idea is that on screens over 600px wide an image that has a size of 1920x650 pixels can be displayed, while on smaller screens an image of 600x587 pixels is displayed.

I would understand that with this <source media="(min-width: 600px)" srcSet={desk} /> the image for desktop would be shown when the screen is 600 pixels or more, while with this <img {...rest} /> a default image for mobiles would be shown when the screen is less than 600 pixels. But the getImgProps function for desktop does not respect the size indicated in the configuration options.

Could you guide me please?

[vicasas]

@leerob something new? When can we see this in the Next.js documentation?

[yasincandev]

Hello. Regarding file format support, is it possible to use different format url in Next/Image? For example, in the picture element, the png format can be activated in the browser that does not support webp. Is the same situation with Next/Image?

[decapination-labs]

do we have similar solution for video tags? having difference source of media portrait for example?