A large share of people run dark mode on their devices, and a meaningful share of web traffic signals that preference. The build decision turns on whether your site uses colour variables, since adding a theme to a token-based site is cheap and retrofitting one onto hard-coded colours is not.

The preference is real

Worth stating plainly, because it is easy to dismiss as a fashion.

Dark mode adoption at the device level is high. Across smartphone platforms most people have it switched on, and among technical audiences the figure is higher still. Surveys of developers routinely find the overwhelming majority working in dark themes.

There is also a genuine practical case. On screens that light individual pixels, dark interfaces use measurably less power, and a substantial share of people report reaching for dark mode in the evening specifically.

So the instinct that people prefer it is correct, and a site that ignores the preference entirely is making a choice rather than a neutral default.

The number that actually decides it

Two different figures get used interchangeably and they are not the same.

Device-level adoption is the share of people who have dark mode enabled on their phone or computer. That figure is high.

Web traffic carrying the preference is the share of requests to websites where the browser signals a dark preference. That figure is considerably lower, and it is the one that matters for your site.

The gap exists because many people run a dark operating system while browsing perfectly happily in light pages, and because desktop adoption trails mobile. Somebody with a dark phone theme is not necessarily somebody who wants your service page inverted.

The honest position is that the share is substantial and not a majority, which makes this a real consideration rather than either a fad or an obligation.

Whose preference you are sampling

A caution worth applying to your own impressions, including mine.

The strongest preference for dark mode sits with technical and design audiences. If you work in web, your colleagues, your peers, and the people who volunteer opinions about your site are drawn from exactly that group.

That produces a genuine impression that everybody wants it, formed from a population that is not your client's customers. A plumbing customer at sixty-five looking for a phone number is a different sample.

The way to settle it for a specific site is to look at your own analytics, which can record the preference signal, rather than at either general statistics or the people around you.

The cost depends entirely on how the site was built

This is the part that changes the answer, and it is why blanket advice is wrong.

Built with colour variables

Where every colour is defined once as a token and referenced everywhere, adding a dark theme means redefining that set of values. It is a design exercise rather than a rebuild, and ongoing maintenance is close to nothing because future changes still happen in one place.

On a site built this way, the argument against is weak.

Colours hard-coded through the stylesheet

Where the same hex value appears in ninety places, adding a theme means finding all ninety, and every future change has to be made twice.

This is where the maintenance objection is genuine, and where a retrofit costs more than it returns for a small brochure site.

Which means the useful question is not whether your site needs dark mode. It is whether your site is built in a way that makes it cheap, and if you are building new, using variables from the start keeps the option open at no cost.

Automatic, toggle, or both

Both, and in that order.

Most people who want dark mode want it to happen without asking. Respecting the preference the browser already signals is what they expect, and it requires no interface at all.

A visible toggle is worth adding on top, because some people want a different setting for one site than for their system, and because a toggle makes the feature discoverable. It should remember the choice.

What does not work is a toggle alone, ignoring the system signal, which makes every dark-mode user perform a manual step your competitor did not require.

The failures to avoid

These hold regardless of the decision above.

Partial implementation is worse than none. A site that themes some elements and not others produces dark text on dark backgrounds and invisible form fields. If you are not doing it fully, declare the site light-only, which browsers respect, rather than leaving it ambiguous.

Not pure black. White on pure black is harsh and causes visual fatigue. Off-white on a dark grey reads considerably better and is the most common amateur mistake.

Images with white backgrounds sit as bright rectangles in a dark layout. Logos with dark wordmarks disappear entirely, so a light-theme variant is needed.

Forms need explicit styling in both themes, since input fields, placeholders, and focus outlines are frequently left to the browser.

Embedded content such as maps, booking widgets, and video players will not follow your theme and appears as a bright block.

Where it matters most

Duration is still the best guide to how much it returns.

Sites people read at length, work in daily, or open at night benefit most. A blog, a documentation site, a portal, or anything with long articles is a strong case.

A five-page brochure site somebody visits for ninety seconds benefits least, and on such a site the same effort spent on contrast, text size, and load speed helps every visitor rather than a subset.

That is a difference of degree rather than a rule, and for a new build using variables it costs little enough that the calculation rarely needs making.

The practical answer

If you are building new, use colour variables and support the system preference. It is cheap at that point and expensive later.

If you have an existing site with hard-coded colours and a short visit duration, the retrofit is hard to justify against contrast and speed work that helps more people.

If you have an existing site people spend real time on, it is worth doing properly, and properly means fully rather than partly. The wider question of what a site commits you to maintaining is covered in static pages versus a database.

Frequently asked questions

Do people actually prefer dark mode?

Device-level adoption is high across smartphone platforms, and higher still among technical audiences. There is also a real power saving on screens that light individual pixels.

Why do adoption figures vary so widely?

Because device-level adoption and web traffic carrying the preference are different measures. Many people run a dark operating system while browsing light pages happily, and desktop trails mobile.

Should I trust my impression that everyone wants it?

Check it against your own analytics, which can record the preference signal. The strongest preference sits with technical and design audiences, which is who volunteers opinions if you work in web.

What decides whether it is worth building?

How the site is built. On a site using colour variables it is a design exercise with almost no ongoing cost. On hard-coded colours it means finding every value and maintaining two sets.

Should I use automatic switching or a toggle?

Both, in that order. Respect the system preference by default since most people expect it to happen without asking, and add a toggle that remembers the choice.

What is the worst mistake?

Partial implementation, which gives dark-mode visitors dark text on dark backgrounds and invisible form fields. Declare the site light-only instead if you are not doing it fully.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Building new, or wondering whether to retrofit?

We build with colour variables so dark mode stays a cheap option, and check your own traffic before recommending a retrofit either way.

Start a Conversation