Safari 27.3 beta can repaint a light website as dark for a visitor who's turned the option on, and the website can't detect it. I checked 24 pages across the 13 sites I monitor, my own included, and none of them declares anything about colour schemes. WebKit says a page that declares support for dark mode is left alone. I haven't run the Safari beta, so this covers what I could measure and says where that stops.
What Safari is adding
WebKit, the engine inside Safari, announced Adaptive Dark Mode on 3 November, and as of 5 November 2026 it's in beta. With the device set to dark, Safari offers a preview when you reach a bright site, and the visitor taps Try.
The signal it looks for is color-scheme, a setting in a page's CSS (the code that styles it) or in a meta tag (a line in the page's head, the part that carries information about the page). It tells a browser which colour schemes the page supports, and light dark says both. For a page that declares light dark, in WebKit's words, Adaptive Dark Mode "does not change a thing". Without a declaration, Safari estimates whether the page is mostly light or mostly dark. A dark page with light text is left alone, and a light page gets adapted.
WebKit's reason is a gap: "Almost 40% of web page loads are from users in dark mode, and yet only 10% of page loads support it." The post doesn't say where that figure comes from, and it doesn't say how many people will turn this new option on.
How the repaint works
WebKit describes a colour matrix that inverts how light a colour is while keeping its hue, so light backgrounds go dark and dark text goes light. Text aims for the 4.5:1 contrast ratio in WCAG, the Web Content Accessibility Guidelines, and light gradients (colour fades written in CSS) are transformed too.
Images are the part a designer will want to look at. Most are left unchanged. SVG images, which are drawn from shapes, are inspected and recoloured when needed. Bitmap images, which are made of pixels, have the spread of their pixel values analysed so that simple black-and-white logos can be inverted. Effects like masks and mix-blend-mode (a style that blends an element's colours with what's behind it) may be turned off in some cases, and canvas content, which a script draws, is left alone. A coloured PNG logo with a transparent background isn't in that description, so my reading is that it stays as drawn, on a background that's now dark. That's my reading of the post, not something I've seen.
Why I don't expect analytics to show it
WebKit says Safari stops websites detecting this. JavaScript, the code that runs in the browser, gets the colour in your CSS rather than the one on screen, and images drawn to a canvas come back in their original form. The reason it gives is privacy. My inference is that analytics can't count these visitors and a script can't report what they saw, and the only way I can see to check a page is to open it in Safari with the option on.
What I found on 24 pages
On 5 November I loaded the homepages of the 13 sites on my monitor, plus the 11 contact pages I could find a link to, in headless Chrome (Chrome run without a window, for automated tests) with dark mode emulated. Analytics and form hosts were blocked, and nothing changed on any live site.
- Declared a colour scheme: 0 of 24, in a meta tag or in any CSS the page loaded. The raw HTML of all 13 homepages agrees.
- Had a prefers-color-scheme: dark rule or light-dark() in that CSS: 0 of 24. I didn't look for themes switched by a class. My own two sites are in that count.
- Homepages where 1% or less of pixels were light: 4 of 13. Homepages between 21% and 65%: 9 of 13. "Light" here means relative luminance above 0.5, a standard measure of how bright a colour looks, averaged over six points down the page.
- Bitmap logos: 7 of those 9 homepages. Two have dark lettering on a transparent background.
- Forms embedded from another host in an iframe, which is a page inside a page: 5 of 11 contact pages.
What that split doesn't tell you
The post doesn't say how WebKit estimates whether a page is light or dark, so the split above doesn't tell you what Safari will do. That goes for the four dark pages as well as the nine. Contact pages on three of those four sites came in at 9% to 20% light, and I don't know where Safari draws the line.
What happens if you say you support dark mode and don't
WebKit names light only as the opt-out, but says the only keyword isn't supported in Safari 27.3 beta 1. It also says a page declaring light dark isn't changed. Its post doesn't address a page with no dark styles behind that declaration, so my reading that the declaration would hold there too is an inference. I expected it to break such pages, because it turns the browser's default page background dark, so I tested it in Chrome.
The mechanism is real. On a test page with a text colour set and the background left to the browser, adding the declaration as a style gave dark grey text on a nearly black page, at 1.18:1 contrast, which you can't read.
Then I ran the 24 real pages in Chrome at desktop and phone widths, 48 runs. I loaded each page as served, then again with the meta tag added to my local copy of the HTML, and compared screenshots of the whole page, counting pixels whose brightness moved by more than 40 out of 255. At that threshold no page's text or background colour changed. The tag had taken effect: on the test page and on three real pages I checked, the browser's default background went from white to near black. My reading is that these pages paint their own backgrounds, so the default never shows.
In 39 runs nothing crossed the threshold. In five, the difference was timing, which I checked by eye: slides moving, a map pin and a review widget image still loading. The other four were one real change on one site, a default browser checkbox on a quote form that turned dark. An earlier run, which added the declaration as a style after the page loaded, also showed the browser's default background flip on all 24 pages, and one form control's text or background colour change on each of 9 pages, which I haven't explained. So I was wrong about these pages breaking at that threshold. What did move was the default background, one checkbox, and those nine form controls.
My first version of this test judged contrast from each element's parents and reported failures that the screenshots didn't show, so I threw it out.
The limits matter more than the result. This ran in Chrome, not Safari, so it measures the declaration's side effects, and whether the declaration stops a repaint rests only on WebKit's sentence. I didn't load third-party forms, and the CSS specification (a W3C Candidate Recommendation Snapshot dated 30 October 2026) says an iframe whose colour scheme differs from the document it embeds gets an opaque background, so those forms could change in a way I haven't seen. I ran with reduced motion on and animations off, didn't test hover, focus or open states, and didn't look for a flash of dark while a page loads.
As I read WebKit's post, the declaration does two things at once. It says the page supports dark mode, which isn't true of a page with no dark styles, and it stops Safari adapting the page for a visitor who turned the option on. That's my reading, not WebKit's wording.
How to sort your own pages
Which signal a page sends Safari comes down to three checks: the meta tag in the page's head, the value the browser ends up using for color-scheme on the page's top-level element and body, and whether the CSS it loads has a prefers-color-scheme: dark rule, light-dark() or a dark theme switched by a class. One check alone can mislead. Searching page source misses external stylesheets, and in my test the computed value still read normal with the meta tag in place.
The choice, as I read it, is which of three signals a page sends: nothing, light dark with dark styles behind it, or light dark with none. I'm leaving only out of the three because it isn't supported in beta 1.
- None of the three checks finds a declaration, and the page reads as light: Safari may adapt it. All 24 of my pages declare nothing, so they sit here or on the next line.
- None of the three checks finds a declaration, and the page reads as dark: WebKit says nothing changes, though that's WebKit's estimate of the page, not yours.
- light dark declared, with dark styles behind it: a real dark mode, and WebKit says Safari leaves the page to you.
- light dark declared, with no dark styles behind it: the case I tested above, in Chrome. WebKit's post doesn't say what Safari does with it.
- only in the value: WebKit names light only as the opt-out, and the specification says only "Forbids the user agent from overriding the color scheme for the element". It isn't supported in beta 1, and I haven't tried it.
One part of a page
WebKit says you can apply color-scheme: light dark to a single element and give it your own dark styles. A logo block or a form, with Safari adapting the rest, are my examples of where that might fit, and I haven't tried either.
Where to start
Look first. Check your own pages for the three things above, and if you've got Safari 27.3 beta, open them with the option on and see what it does. I haven't.
What this can't tell you
None of this ran in Safari. WebKit's post says the option evolves through the beta process, gives no date for a stable release and doesn't say how a form from another host gets treated. The specification adds a Note that the specifics of the automatic adjustment are up to each browser. My numbers cover homepages and contact pages, not whole sites.
What to read next
Astro or Next.js for a business website?
My rule for choosing between Astro and Next.js, and what two of my own sites send on first load, measured with PageSpeed Insights on 25 October and 5 November 2026.
Read articleCustom-coded vs WordPress: a real-world speed comparison
The same local business, the same services, one website replaced by another, both measured with Google PageSpeed Insights on the same day. Not a laboratory test, but the closest the real world gets.
Read articleWhy I don't start with WordPress (and where it's still the right call)
A first-person case for choosing the platform last, with the one comparison I've measured and five questions to ask before you agree to any platform.
Read articleQuestions local business owners usually ask next
Want someone else to look at your site?
Send me the address and I'll review the site you've got now. It's free.