WebKit now repaints light-only sites dark for users who've turned the setting on — without asking the page's permission first. Here's how the transform works, what one line of CSS does to opt out, and why it matters beyond the browser itself.
Apple's WebKit team introduced Adaptive Dark Mode in the Safari 27.3 beta released November 3, 2026, and it quietly changes a long-standing assumption: that a website's colors are the website's business. The feature analyzes a page, estimates whether it's predominantly light, and if the user has the setting on, repaints it dark — whether or not the page ever planned for that. Early coverage flagged the obvious tension this creates for sites that style their own dark mode carefully and don't want the browser doing it for them. For teams that maintain WebView-based screens as part of broader iOS app development work, the behavior matters even where there's no Safari tab in sight: anything rendered through WKWebView inherits it too.
The mechanism is a color matrix applied inside the WebKit engine, not a CSS filter the page can inspect. WebKit describes it as inverting the luminosity of colors while preserving their hue, so a light-blue background becomes a dark blue rather than an arbitrary dark gray, and text color transforms are tuned to land at or above the WCAG 4.5:1 contrast ratio. Most photographic images are left untouched because inverting a photo looks wrong; WebKit instead inspects simple black-and-white bitmap logos and SVG graphics and transforms those selectively, while effects like mix-blend-mode can be disabled where the transform would produce a broken result. Canvas content is left alone entirely, since there's no reliable way to know what's being drawn into it.
The one thing every page keeps control over is the opt-out: <meta name="color-scheme" content="light dark"> in HTML, or color-scheme: light dark in CSS, tells WebKit the page already handles its own dark appearance, and Adaptive Dark Mode leaves it untouched. A stricter light only value is documented as the way to say "stay light, period," but it isn't functional yet in beta 1 — so right now, declaring dark-mode support is also the only working way to opt out of the automatic repaint, even for a site that has no real dark theme to show.
WebKit built in a deliberate blind spot: a page has no way to detect that Adaptive Dark Mode is active. As the team puts it, JavaScript that queries CSS colors gets back the original authored values, not the transformed ones, and anything drawn into canvas renders in its original, untransformed form. That's a fingerprinting decision as much as a rendering one — if sites could detect the setting, it would become one more bit of distinguishing information trackers could read off a visitor. The side effect is that analytics, A/B tests, and ad-creative QA all keep reporting the colors you authored, even while a meaningful share of users are actually seeing something else on screen.
color-scheme is no longer optional polish. A site with no dark theme at all should still ship color-scheme: light (or the HTML meta equivalent) in Safari 27.3 and later if it wants predictable colors rather than WebKit's best guess at an inversion.color-scheme early in the document and use @media (prefers-color-scheme: dark) or the CSS light-dark() function for an intentional dark theme, rather than toggling classes after the fact.color-scheme declaration or a format change.Adaptive Dark Mode landed in the Safari 27.3 beta channel on November 3, 2026, alongside the broader Safari Technology Preview 256 release the following day. Beta features typically reach stable Safari on Apple's regular OS update cadence, which has historically run weeks to a couple of months after a feature first appears in beta. The light only opt-out keyword specifically is called out as non-functional in beta 1, so teams testing now should expect that particular control to firm up in a later beta before the feature reaches general release.