Apple's WebKit team on November 3, 2026 introduced Adaptive Dark Mode, a Safari 27.3 beta feature that recolors websites built only in light colors so that they display dark for users who switch it on. The post, signed by Simon Fraser, Luming Yin, Lily Spiniolas, Joanne Pan, Veda Periwal and Jen Simmons, describes a color transformation that runs inside the WebKit engine, reaches text, buttons, gradients and some images, and is deliberately hidden from the page it changes. Scripts that ask the browser for a page's colors receive the colors the site wrote, not the ones on screen.

"We're excited to announce Adaptive Dark Mode in Safari 27.3 beta," according to the post. "When enabled by a user, Safari adapts light websites and presents them as dark."

In Short

Safari's test version can now make bright websites dark for people who prefer dark screens, even when the website never built a dark design of its own. That matters to publishers and advertisers because the colors of their pages, and possibly of some ads on them, can change on screen without any of their code being able to see it. A site that wants to stay light will be able to say so with a one-line instruction, but that instruction does not work yet in the first test version.

Offered by the browser, enabled by the user

Adaptive Dark Mode is off unless a user turns it on. The route to that decision, though, runs through Safari itself. According to WebKit, a user first sets the system appearance to dark and then visits "a website with a bright background." At that point "Safari will offer a preview of Adaptive Dark Mode," and the user taps "Try."

The browser, in other words, makes the offer on the light pages it encounters. A light site does not need to do anything to trigger it. The only exemptions the post describes are declarations a site makes in its own code, covered below.

Several practical details are missing. The post does not list the platforms on which the beta runs. Its instructions use the word "tap," which points to iPhone and iPad, but Mac and Vision Pro are not mentioned either way. No date is given for the final Safari 27.3 release, and the post expects the feature to change before then: a note on the opt-out keyword refers to "Safari 27.3 beta 1" and asks developers to "check back as Adaptive Dark Mode evolves through the beta process."

The 40% and the 10%

WebKit frames the feature as unfinished business from more than seven years ago. "In the spring of 2019, Safari 12.1 became the first browser to support dark mode on the web," according to the post. Dark mode on the web, in that sense, means a site can detect a user's preference and serve its own dark styles. According to the figures the post cites, most sites still do not.

"A lot of people love using dark mode, but not every website has a dark version," the post continues. "Almost 40% of web page loads are from users in dark mode, and yet only 10% of page loads support it."

Those figures are not Safari's. The post links both numbers to Chrome Platform Status, the public dashboard where Google publishes usage counters collected from Chrome. The post gives no Safari equivalent and no time period for either number. Taken at face value, they describe a large mismatch: a substantial share of the web's audience asks for dark pages, and the large majority of page loads do not provide them. "Adaptive Dark Mode is designed to close that gap, providing a consistent dark experience across the web," according to WebKit.

How the transformation works

Before changing anything, Safari checks whether the site has declared dark mode support. A page that signals it through the HTML tag <meta name="color-scheme" content="light dark"> or the CSS rule color-scheme: light dark is left alone. "Adaptive Dark Mode does not change a thing," according to the post.

For the rest, Safari "quickly analyzes the page, looking at colors and estimating whether it's predominantly light or dark." A page that already has a dark background with light text is not modified. A page with a light appearance is converted.

Color

"At the core of Adaptive Dark Mode is the transformation of color," according to WebKit. The team says it developed a color matrix that inverts the luminosity of colors while preserving their hue. Applied to a typical page, that turns light backgrounds dark and dark text light, while keeping each color in the same family: navy text would become a lighter blue, and a pale background would become a deep shade of the same tint.

Text gets a target. "When transforming text color, Adaptive Dark Mode aims for sufficient contrast as defined by the WCAG 4.5:1 contrast ratio," the post states, referring to the minimum contrast level set out in the Web Content Accessibility Guidelines. Light CSS gradients are also converted to dark.

The post also says the transformation makes judgments about whether a color carries meaning. "Sometimes colors are simply decorative, while other times they have semantic meaning," according to WebKit, and the engine decides "when to invert colors so elements remain visible or when to leave colors unchanged." The stated aims are practical: "buttons have contrast against backgrounds, text is visible over images, and hover menus look clear." The post does not explain how semantic color is identified.

Images

Photographs and other images are mostly untouched. "Most are left unchanged, preserving their integrity," according to WebKit. The exception is graphics that would disappear once the background behind them is darkened. Safari inspects SVG images and transforms their colors when needed. For bitmap images, it "analyzes the pixel histograms and inverts simple black-and-white logos."

The example in the post shows a travel-style booking page three ways: in its original light design, under Adaptive Dark Mode, and with a custom dark theme of the kind a site could build itself. In the adapted version the large photograph at the top of the page is unchanged, while the panels, cards and text around it turn dark.

Effects and canvas

Two categories receive blunter treatment. Masks and the CSS mix-blend-mode property "can create undesirable results on an element whose colors have been transformed," according to the post, so "in some cases Adaptive Dark Mode turns such effects off." Content drawn into the HTML <canvas> element is left as it is, "since canvases contain a wide range of content that's hard to predict."

WebKit attributes the approach to where the feature sits. "It's precisely because Adaptive Dark Mode is happening deep within the WebKit browser engine that we are able to find creative ways to solve the most complex challenges, apply the transformations with great speed and power efficiency, all while rigorously protecting user privacy," according to the post. No performance or battery figures are provided.

What happens to ads

The post does not mention advertising. It says nothing about ads, iframes, third-party scripts or embedded content of any kind. Read against the mechanics it does describe, though, the effects on ad units would vary sharply by how a creative is built.

Image banners. A display ad delivered as a photograph or a full-color bitmap falls under the rule that most images are left unchanged. On a page that Safari has darkened, a banner designed with a white background would therefore remain a bright rectangle on a dark page.

Logos. Advertiser and sponsor logos supplied as simple black-and-white bitmaps are the one image type the post says Safari may invert. A logo supplied as an SVG file may have its colors transformed when Safari judges it necessary. The post gives no threshold for either decision.

HTML and CSS creative. Ads that draw their backgrounds, buttons and text with CSS are the units most exposed to the color matrix, since that is the layer the transformation rewrites. The same applies to formats assembled from templates, such as dynamic creative optimization, and to native advertising units that inherit the publisher's own styles so that they match surrounding editorial content. A brand color specified in CSS would keep its hue but not its lightness.

Canvas creative. Ads that render inside a <canvas> element are, by the post's own rule, left as authored. So are any effects built on masks or blend modes that Safari decides to switch off, which could leave such a unit looking different from its design in the other direction.

Frames. The largest open question is whether the transformation crosses into frames at all. Programmatic display ads are commonly served inside iframes, often from a different domain from the page. The post does not say whether Adaptive Dark Mode analyzes framed documents separately, applies the parent page's decision to them, or leaves them alone, nor whether a color-scheme declaration inside an ad's frame is honored. For publishers, that answer would determine whether a darkened article page carries darkened ads, bright ads, or a mixture.

Invisible to the page

The design choice with the widest consequences sits near the end of the post, under the heading "Protecting user privacy."

"Apple firmly believes user privacy is a fundamental human right," according to WebKit. "If websites could detect when a user has enabled Adaptive Dark Mode, that would increase the amount of fingerprintable information and weaken privacy protections against trackers."

Safari's answer is to conceal the transformation entirely. "Safari prevents websites from detecting when Adaptive Dark Mode has been applied," the post states. "JavaScript that queries CSS colors will get the original authored colors, not the transformed ones. Any images drawn into canvas render in their original form."

The second sentence closes the obvious workaround. A script that paints part of the page into a canvas and reads back the pixels, the same technique behind canvas fingerprinting, receives the original image rather than the adapted one. The reasoning follows a line Safari has pursued for some time. In 2025, Safari 26 extended Advanced Fingerprinting Protection to all browsing by default, having previously limited it to Private Browsing.

A page can still learn through the long-standing prefers-color-scheme media query that a visitor's system is set to dark. What it cannot learn is whether Safari has repainted the page in response.

For the businesses that sell and measure advertising, that removes a signal before it ever existed. A publisher cannot count how many Safari visitors see its pages in adapted form, cannot segment analytics by it, and cannot compare engagement on adapted and unadapted pages. An advertiser cannot learn from its own tags whether a creative ran in its authored colors. Viewability measurement, which rests on how much of an ad is on screen and for how long, is not obviously affected, since nothing in the post suggests that layout changes. But any script that reports on how a creative looked, rather than where it sat, would report the design as delivered, not as displayed.

The post offers two feedback routes in place of telemetry. Site owners who want to discuss how the feature handles their pages are invited to write to web-evangelist@apple.com, and users who find a site that does not work well are asked to file a report through Apple's Feedback Assistant.

The opt-out that beta 1 does not support

WebKit does describe a way to keep a page out of the transformation. The HTML tag <meta name="color-scheme" content="light only">, according to the post, tells browsers that the page "supports light mode" and "should only be displayed in light mode." A CSS equivalent, color-scheme: light only, does the same with what the post calls "the flexibility of CSS": it can be applied to specific elements on the page, or to the whole page through the :root selector.

That element-level option is the one that matters for ad slots. In principle, it would allow a publisher to hold a container at its authored colors while the rest of the page darkens, subject to the unanswered question of how frames are handled.

It does not work yet. "Note: the 'only' keyword is not supported in Safari 27.3 beta 1," according to the post. In the current beta, therefore, the only documented way for a light site to avoid Adaptive Dark Mode is to declare support for dark mode with light dark, which tells Safari the site handles dark mode itself.

Timing also counts. The post says sites should declare their color-scheme in the HTML head or in CSS on :root or body, and warns: "Don't wait to inject this information later via JavaScript." According to WebKit, declaring it up front is a "best practice" so that a site is rendered correctly "as fast as possible." Sites that load their style declarations through tag managers or late-running scripts may find Safari has already analyzed the page by the time the declaration arrives, although the post does not describe the exact sequence.

WebKit's guidance for older sites

The post groups its remaining material into guidance for site owners, and it is unusually specific about which building techniques the transformation handles poorly. "In general, a web page will work well with Adaptive Dark Mode if it follows good modern web development practices," according to WebKit.

The list of older techniques it names is a description of where the feature struggles: bitmap images used for logos and icons, which it suggests replacing with SVG; tiled background images in place of CSS colors and gradients; image sprites used for rounded corners, shadows and button states; content images with the page's background color "baked" into them rather than transparent backgrounds; and containers without padding, which the post says can look crowded.

For sites that want full control, the post lists the standard tools: the color-scheme meta tag and CSS property, the prefers-color-scheme media query, the <picture> element with a dark-mode source, and the light-dark() CSS function. It also names the newer color-mix() and contrast-color() functions. WebKit calls the support for these "widely available today."

A site can also mix approaches. According to the post, applying color-scheme: light dark to a single element and adding custom dark styles lets a site define its own dark treatment for "a certain portion of the page" while Safari handles the rest.

A different kind of WebKit post

The announcement lands in a busy stretch for Apple's browser team, much of it about tracking. Safari 27 shipped this autumn with a block on The Trade Desk's ad domain, which PPC Land traced to 11 lines of code WebKit merged in February. On October 19, WebKit explained that Safari 27 blocks identity resolution firms that turn email addresses into tracking IDs. Safari 27.1 followed on October 23 alongside iPhone Duo, with viewports from 382 to 951 pixels wide and no tracking changes. Three days later, Safari 27.2 dropped a mistaken seven-day cap on cookies set by CNAME-hosted sites among 20 bug fixes.

Adaptive Dark Mode changes what a page looks like rather than what it can collect, and the post says nothing about tracking prevention, cookies or the domain blocks. Yet it ends on the same argument as the tracking posts: any new piece of information a browser exposes about its user is a potential identifier, so Safari withholds it. For publishers, the result is a feature that alters how their pages and possibly their ads appear to a share of Safari users, with no measurement of how large that share becomes. The size of that share will depend on how readily dark-mode users tap "Try," and on whether the final release lets sites say no.

Timeline

Summary

Who: Apple's WebKit team, in a post by Simon Fraser, Luming Yin, Lily Spiniolas, Joanne Pan, Veda Periwal and Jen Simmons. The feature affects Safari users who opt in, and the publishers and advertisers whose light-colored pages and creatives those users see.

What: Adaptive Dark Mode, which analyzes light websites without declared dark-mode support and recolors them dark by inverting luminosity while preserving hue, targeting WCAG 4.5:1 text contrast. Most images are unchanged, simple black-and-white bitmap logos and some SVGs are transformed, canvas content is untouched, and some masks and blend effects are switched off. Websites cannot detect the change, and the light only opt-out is not yet supported.

When: Announced November 3, 2026, in Safari 27.3 beta 1. No date has been given for the final release.

Where: In the WebKit engine inside Safari 27.3 beta. The post does not list platforms, though its instructions to tap "Try" point to iPhone and iPad.

Why: WebKit cites Chrome figures showing that almost 40% of page loads come from users in dark mode while only 10% of page loads support it. The detection block is justified as a privacy measure, because a detectable setting would add fingerprintable information. For publishers and advertisers, the consequence is a change in how pages and some ads appear that their own scripts cannot see.