Safari Dark Mode for Websites: How to Test Apple's Beta

WebKit introduced a way to force Safari dark mode for websites that never built one themselves. The feature, called Adaptive Dark Mode, arrived in Safari 27.3 beta last week and only applies once a user turns it on, according to WebKit's announcement.

WebKit built the feature to close a specific gap. Almost 40% of page loads come from users already browsing in dark mode, but only about 10% of pages actually support it, WebKit says. Safari was the first browser to support dark mode on the web, when Safari 12.1 shipped in the spring of 2019, and Adaptive Dark Mode extends that groundwork to sites that never built a dark theme of their own.

Availability is narrow for now. WebKit says the feature is available to test in Safari 27.3 beta, although its announcement does not specify a full device-support matrix. Anyone not running that beta will have to wait for Apple to say more about a wider rollout.

Who can turn on Safari's website darkening feature right now

Turning it on requires two things: Safari 27.3 beta and a system appearance already set to Dark. With both in place, opening a light website triggers a preview prompt, and tapping "Try" applies the transformation, WebKit explains.

One opt-out is not working yet. Sites can ask to be excluded from the transformation with a color-scheme: light only declaration, but WebKit's own post flags that the only keyword is not supported in Safari 27.3 beta 1. Because of that, developers cannot rely on that opt-out in this build, and WebKit says to check back as the feature evolves through the beta process.

No compatibility list for operating systems or devices has been published. If the prompt does not appear on a page, verify the Safari version and system appearance before treating that as a feature failure.

How Safari decides which sites to darken

Not every site gets touched. Pages that already declare support for both color schemes, through a color-scheme meta tag or color-scheme: light dark in CSS, are left alone entirely; WebKit says Adaptive Dark Mode "does not change a thing" on them.

That distinction matters. A site with its own authored dark theme is showing colors its designers chose. A site Safari transforms is getting the browser's best guess at a dark layout instead. WebKit's post illustrates the gap directly, comparing a light version of a page, the same page after Adaptive Dark Mode is applied, and a version with a custom dark theme built by the site, noting the two can look noticeably different.

For sites without a declared color scheme, Safari scans the page's colors and estimates whether it reads as predominantly light or dark, according to WebKit. Pages that already look dark are left untouched. Light pages get transformed using a custom color matrix that inverts luminosity while preserving hue, turning light backgrounds dark and dark text light.

Text transformation targets a WCAG 4.5:1 contrast ratio, and WebKit says the system makes similar judgment calls elsewhere, aiming to keep buttons, text over images, and hover menus usable once colors shift. That is a stated design goal, not a result independently verified on every page, and it's a big part of why checking individual sites still matters.

Safari dark mode website compatibility: how to test websites in Safari dark mode

This is an automated judgment system, not a blanket color invert, so results vary by site. Here's what to check on the pages used regularly, and why each item matters.

• Logos, icons, and illustrations. What changes: Safari inspects SVG images and may recolor them, but bitmap images are judged by pixel histogram, so typically only simple black-and-white logos get inverted, per WebKit. Why it matters: mismatched treatment between a logo and nearby icons is a cosmetic issue, not a readability problem.

• Canvas-based tools. What changes: content drawn with <canvas>, including charts, in-browser editors, games, and any images drawn directly into the canvas, renders in its original form, since WebKit says canvas content is too unpredictable to transform safely. Why it matters: a bright white canvas sitting inside an otherwise dark page is expected behavior, not a bug.

• Masked or blended visual effects. What changes: WebKit notes that effects like masks and mix-blend-mode can look broken once colors are transformed, so Safari sometimes turns them off on affected elements. Why it matters: missing overlays or flattened graphics on design-heavy sites fall into the same cosmetic category as logo mismatches.

• Forms, dropdowns, and date pickers. What changes: this is the category worth the closest look. A separate Safari Technology Preview build, version 256, released this past weekend, includes fixes to date-picker appearance under automatic dark mode and corrects a rotated custom-select hover state, Frebock reported. That's useful context for anyone tracking fixes across WebKit's test builds, but it does not establish that Safari 27.3 beta's Adaptive Dark Mode shares the same bugs or the same fixes, since the two builds track different WebKit revisions. Why it matters: if a calendar picker or dropdown hover state is hard to read during checkout or login, that's a functional problem worth verifying on the specific workflow rather than assuming it's already resolved.

• Text over photos and hover menus. What changes: Safari targets that 4.5:1 contrast ratio when transforming text, per WebKit, but a design target isn't a guarantee on every page. Why it matters: captions or labels sitting on a now-dark image are worth a second look, especially on sites read for long stretches.

What developers should know before WebKit dark mode testing continues

WebKit's position for site owners is straightforward: the web already has the tools to support dark mode properly, so the fallback shouldn't be the plan. WebKit's post points to color-scheme and the light-dark() function as already widely available, and recommends declaring color-scheme directly in HTML or CSS at load time rather than injecting it later with JavaScript, so the browser renders the page correctly from the first paint.

The color-scheme: light only opt-out exists in the specification, but it's not functional in Safari 27.3 beta 1 yet, so it can't be treated as a reliable way to block the transformation today.

Sites also can't detect the transformation after the fact, and WebKit explains the reasoning: if a website could tell that a visitor had Adaptive Dark Mode turned on, that would add a new piece of fingerprintable information and weaken privacy protections against trackers. As a result, Safari blocks JavaScript from detecting whether the feature has been applied, and any query for a CSS color returns the originally authored value rather than the transformed one.

What's confirmed and what's still open

A few things are settled, and a few aren't. Confirmed: Adaptive Dark Mode works today in Safari 27.3 beta, is opt-in, and leaves sites with their own color-scheme declaration untouched. Unsupported in this build: the color-scheme: light only opt-out, which WebKit says developers shouldn't rely on yet. Unknown: when, or whether, this reaches a stable Safari release, since WebKit's announcement doesn't name a timeline or list which devices and operating systems will eventually support it.

What to do with Adaptive Dark Mode today

For everyday reading and casual browsing, leaving Adaptive Dark Mode on in the beta is a reasonable way to see how it handles the sites already in daily use. For banking, checkout, dashboards, or anything built around a form that needs to stay readable, test the specific site first, since the fixes referenced in Safari Technology Preview 256 haven't been confirmed in this particular beta.

If a site misbehaves, turn the feature off for that session and file a report through Feedback Assistant, which is what WebKit is asking testers to do, rather than assuming a later beta quietly fixed it.