Safari 27.3 Will Auto-Darken Light-Only Sites. Declare Your Color Scheme Before Users Meet Your Site Inverted.
On November 3, the WebKit team announced Adaptive Dark Mode, previewed in the Safari 27.3 beta. When a user turns it on, Safari detects pages with a light theme and renders them in dark colors, whether or not the site's author ever wrote a dark theme. If you ship a landing page, a SaaS dashboard or a docs site with only light styles, some of your Safari visitors may soon see a version of it you have never looked at.
What Safari changes
According to the WebKit post, Safari adjusts colors while keeping their hues and aims for a 4.5:1 text contrast ratio, the WCAG threshold for normal text. Light gradients are darkened. SVG colors and simple black-and-white bitmap logos may be inverted when needed. Most photos are left alone, and <canvas> content is not changed. WebKit also warns that some masks and mix-blend-mode effects may be turned off.
Three kinds of pages are left alone: sites that declare dark support with color-scheme: light dark, pages that already have a dark background with light text, and anything the author opts out. So the exposure is specific: light-only pages that declare nothing.
The two fixes
If you want to support dark mode, the signal is color-scheme: light dark on :root, plus real dark styles. Declare it without dark styles and you mostly change how browser defaults such as form controls and scrollbars look, which can be fine or can look half-finished, so test it.
If your design is light only on purpose, WebKit's answer is the only keyword. In HTML that is <meta name="color-scheme" content="light only">, and in CSS it is color-scheme: light only on :root for the whole page or on specific elements. There is a catch: the post says the only keyword was not supported in Safari 27.3 beta 1, and tells developers to check later betas. So the opt-out you would rather use may not work yet in the build people are testing.
What I'd test first
The risky parts of an automatic transform are the things a designer hard-coded. I would open my own pages with the feature on and look at logos, especially single-color SVGs and PNGs with a transparent background, since those are the ones WebKit says may be inverted. Then screenshots and diagrams that include a white background, then any custom mix-blend-mode, then charts drawn in SVG, where the color choices carry meaning. A chart where the legend and the bars were recolored by different rules is a bug a customer will find before you do.
I would also check embedded content. A widget in an iframe from a third party may be transformed on its own terms, and I have no information on how Safari treats cross-origin frames here. The WebKit post does not say.
Where I could be wrong
This is a beta feature that users must turn on. I do not have numbers for how many Safari users will enable it, and the behavior may change before release or may never ship in this form. The post does not give a release date for 27.3, and I am not assuming one. If your traffic is mostly Chrome and Windows, the payoff of this work is small.
There is also a fair argument for ignoring it: a user who forces dark mode on every site accepted that sites will sometimes look off. I think that argument is weak for a product people pay for, because the support email comes to you anyway.
What I'd actually do
If I had no dark theme and no plan to build one, I would add the light-only meta tag now. It costs one line, and on a build that supports only it settles the question for the pages that need it. Then I would retest when a later 27.3 beta lands, because a tag that is silently ignored is not protection.
If I did want dark mode, I would not rely on Safari's guess. I would write the dark styles for the three pages that carry the product, declare color-scheme: light dark, and let the rest fall back. Ten minutes of CSS and one afternoon of screenshots beats an inverted logo.
Author
Lukas
@lukcombinator