Adaptive Dark Mode arrives in Safari 27.3 beta for light-themed sites

WebKit has added Adaptive Dark Mode to Safari 27.3 beta. When users choose it, the browser adapts light-themed sites for dark mode. Here’s what site owners should check.

· 4 min read · 4 comments

WebKit has introduced Adaptive Dark Mode in Safari 27.3 beta. As the WebKit Blog reported in a post dated November 3, 2026, the feature adapts light-themed sites for viewing in dark mode when users choose to enable it. If a site has already declared support for a dark theme, the browser leaves its design unchanged.

According to WebKit, nearly 40% of page loads come from users in dark mode, but only 10% are for pages that support it. The feature aims to narrow that gap and make browsing more consistent, even when a site has no dark theme of its own.

How the browser changes a page

You can try the feature in Safari 27.3 beta: switch your system to dark mode and open a site with a light background. Safari will offer a preview of Adaptive Dark Mode; click “Try” to enable it.

First, the browser checks whether the site declares support for both themes with <meta name="color-scheme" content="light dark"> or the CSS property color-scheme: light dark. It leaves those pages unchanged. Otherwise, Safari assesses the dominant colors: it leaves pages with dark backgrounds and light text as they are, and adapts light ones.

WebKit uses a transformation that changes lightness while preserving hue: light backgrounds become dark, and dark text becomes light. Light CSS gradients are transformed too. For text, the system aims for a WCAG contrast ratio of 4.5:1. The browser also checks that text over images stays readable, buttons remain noticeable, and menus stay visible.

Most images remain unchanged. But if an icon or logo loses contrast against its new background, Safari may adjust the colors in an SVG. For raster images, the browser analyzes the color distribution and may invert a simple black-and-white logo. The contents of <canvas> do not change. Sometimes the browser disables masks or mix-blend-mode if the effect looks wrong after the colors change.

A site cannot detect whether a user has enabled Adaptive Dark Mode. When JavaScript queries CSS colors, it gets the values set by the page author, and images drawn in a canvas keep their original appearance. WebKit says this protects against tracking: detecting the feature would give sites another signal they could use to identify a user.

What to check on your site

Site owners and teams should open key pages in the Safari beta with the feature enabled. I’d start with places where color conveys meaning or helps people take action: buttons, element states, logos, menus, and text over images. Automatic adaptation takes these cases into account, but it doesn’t replace checking the interface yourself.

For pages built with older design techniques, WebKit suggests replacing raster icons and logos with SVGs, tiled background images with CSS colors or gradients, and sprites used for rounded corners, shadows, and button states with CSS. Content images are better prepared with transparent backgrounds rather than the page’s background color baked in. Padding inside containers can help keep things from feeling cramped.

If you need a predictable result, you can build your own dark theme. Tools for this include prefers-color-scheme, light-dark(), CSS variables, and images selected through <picture> based on the user’s theme preference. WebKit recommends declaring support for both themes in HTML with color-scheme, or in CSS on :root or body, rather than waiting for JavaScript to run. For a particular section of a page, you can set color-scheme: light dark and provide your own dark styles.

You can tell the browser that a page or individual element should stay light with color-scheme: light only. But this does not work yet in Safari 27.3 beta 1: the only keyword is not supported.

My take: an automatic theme isn’t a finished design

I like that Safari is trying to soften the abrupt switch between a dark interface and a light site without requiring every page to be redesigned immediately. For a small project, that could make a first visit more comfortable. But I wouldn’t treat automatic conversion as a solution to everything: if color highlights an important action or distinguishes between states, you need to check that the meaning survives by looking at the page, not just at the CSS values.

I’d use this beta as a chance to review a site’s visual system without rushing. First, make sure the pages still make sense after adaptation; then decide where the browser’s work is enough and where you need a dark theme of your own. It’s worth discussing this with a developer, too: understanding how color-scheme is declared and how the styles are built helps turn design feedback into specific fixes.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

  1. Introducing Adaptive Dark Mode webkit.org

About the author

Rocío Gil

junior web designer

I help small projects put together their first pages and portfolios. I enjoy finding a calm visual system even when the client has brought five references, all from different eras.

All posts by the author

Leave a comment

Not published. We’ll send a link to confirm your comment.

No links or ads. Your first comment is published after review. By sending a comment you agree to the privacy notice.

  1. one extra check i’d add: test images with transparent backgrounds and brand colors, not just the page’s CSS colors. In one of my practice layouts, an icon looked fine on white but nearly disappeared once the background changed; an automatic theme can’t always guess which contrast was intentional.

    1. @lenka.adam i’m not sure the icon disappearing is something the browser should be expected to fix, though. Transparent assets and brand colors often encode deliberate design choices, and an automatic inversion can be just as wrong as leaving them alone; i’d treat this as a reason to test the opt-in preview and provide an authored dark theme where contrast matters, not as evidence the browser can reliably infer intent.

      1. Just to clarify, I don’t think Lenka is saying the browser should reliably infer intent or fix every asset—only that transparent images and brand colors are worth checking in the preview. An authored dark theme is the safer choice where contrast is important, but the preview can still reveal issues owners might otherwise miss.

        1. @helen_hall I’ve seen this in practice with a transparent logo that looked fine on a white header but picked up an awkward halo against a darkened background. The Safari preview is useful for catching that kind of edge case; for anything central to the brand, I’d still ship an authored dark variant rather than rely on the browser to infer the intended contrast.