Rethinking Dark Mode Image Strategies with Media Queries in HTML

Distributed on 31 Oct, 2025

You know how macOS’s dynamic wallpapers change color schemes depending on what time of day it is? I think that’s a pretty cool and thoughtful little design detail.

If you’re adapting your website to user preferences, you’re probably using the prefers-color-scheme feature query in CSS to adapt the colors of your website depending on the user’s preferred color scheme.

So here’s a question for you: How are you handling your images between light and dark modes? Are you swapping background images between light and dark modes? What about your content images (i.e. images embedded in your HTML, not in your CSS)?

A very common approach to making content images (such as images within articles) adapt to dark mode is to dim the images by decreasing their opacity when dark mode is detected:

@media (prefers-color-scheme: dark) {
	img {
		opacity: .5;
	}
}

…or by using the filer property to decrease the image’s brightness:

@media (prefers-color-scheme: dark) {
	img {
		filter: brightness(.75);
	}
}

The idea here is that some images may be too bright for someone who prefers an overall dark color theme, especially if this preference is based on an accessibility need such as light sensitivity, not just an aesthetic preference.

However, this approach also makes the images less accessible overall. With a lower contrast overall, the images, especially those containing meaningful text, become much more difficult to perceive.

I was reading through an article the other day and wondered why the images had such low contrast. I thought it was just my display or, well, my eyes just being too tired. Then I accidentally hovered my mouse on one of the images. When I did, the image got its full opacity back and become more perceivable. That’s when I realized that the opacity had been reduced because I was in dark mode on OS level.

That’s the general approach: images are dimmed in dark mode, and their brightness is fully restored when they are hovered.

Dimming all content images like that is not an inclusive design strategy. For starters, it makes many images less accessible. And the fact that they need to be hovered using a pointer device to become fully visible makes the issue worse. How would someone using a keyboard increase the opacity of these images to see them better? (No, making the images focusable is not how.)

If you don’t want to keep the same images in both light and dark mode, then Instead of decreasing the opacity of the images, the alternative can be to use feature queries in the <picture> element and render the image suitable for each mode.

More specifically, you would use a feature media query to determine the source of an image depending on which color scheme the user has chosen:

<picture>
  <source
    srcset="/path/to/dark-theme-image.jpg"
    media="(prefers-color-scheme: dark)" />
  <img src="/path/to/light-theme-image.jpg" alt="[ appropriate alt text ]" />
</picture>

This way, you’re able to supply a light-themed image in light mode, and swap that for a dark-themed image in dark mode, instead of reducing the light image’s opacity in dark mode.

Here’s a quick and dirty Codepen of this technique in action:

See the Pen Responsive images in dark and light mode by Sara Soueidan (@SaraSoueidan) on CodePen.

Here is a screen recording demonstrating the image in the Codepen change when I switch modes on macOS:

I do wish the <source> element also accepted an alt attribute (or similar) so that we can provide a suitable and more descriptive alt text for each version of the image. Maybe then the browser could populate the <img>'s alt text with the text we provide for each source.

You may be thinking: Why would you want to provide separate alt text if it’s the same image?

Sure, if you’re providing the same image in both modes just with different colors for each mode then you might be OK using the same alt text for both versions. But if the different versions of the image are meant to convey a certain vibe and you want that vibe communicated to assistive tech users, then having separate alt texts for each version would be helpful.

Images can convey emotion, or evoke it, and communicating emotion through to screen reader users creates a more equitable experience for them. There are even opinions amongst accessibility professionals that agree that even decorative images might benefit from alt text if they are used to convey a certain vibe or express or evoke a certain emotion.

Another reason providing separate alt text can be useful is if you’re providing cropped versions of the same image depending on the viewport size. Art-direction, basically. This may sometimes necessitate different alt texts, particularly if the different versions include more elements that might be worth communicating to the user.

Another thing I wish we had is the ability to transition between versions of an image. I don’t know but something like view transitions between different picture sources? Crazy, maybe. But certainly something I’d love to have for effects similar to the dynamic wallpapers.

Now, if your images are illustrations of things and you are using SVG to embed them, you can use the media query inside your SVG image. But that’s a topic for another day.