Dark mode toggles: two states are enough • Lea Verou

Dark mode toggles: two states are enough

6 August 2026

9 min read

On this page

Tri-state toggles are implementation-driven UI<br>But what’s the harm?<br>If not three states, then what?Interactive demonstration<br>But what if users get confused?

When is a tri-state control appropriate?1. Color scheme setting that lives a separate settings panel<br>2. When color schemes are implemented differently depending on the system setting

The general version

Yes, the underlying model must have three states, but one is always irrelevant to the actual user goal. Users do not seek out solutions to problems they don’t currently have. A lot of the hate towards two-state toggles is based on poor implementations.

UX,

Usability,

Product Design,

Dark Mode

A good two-state toggle can actually express all three data model states.

Until recently, if you looked at most websites with a theme toggle[1]Unless otherwise noted, this refers to a permanently visible toggle in the header or (rarely) footer, not a theme setting in a separate settings panel. , you’d find three options: Light , Dark , and System .

Examples of tri-state dark mode toggles.<br>In (LTR) reading direction: Ant Design, Red Hat Design System, Web Awesome, Excalidraw, Taiga, Astro, Hero UI.

Thankfully, these days the trend has shifted towards a simpler two-state toggle, but tri-state ones are still incredibly common.

Examples of two-state dark mode toggles.<br>In (LTR) reading direction: Vitepress, Material Design, Adobe Spectrum, Radix, ShadCN.

The rationale sounds plausible:<br>“System” is a different intent than “Light” or “Dark”!<br>One is a policy (whatever my OS says, do that)<br>The other is a value (dark, forever, I don’t care what my OS says.)<br>Surely, users should be able to express that intent!

Except, real users don’t generally seek out dark mode toggles to express intent for things to stay as they are, they seek them out when things need to change.

Think of the user goal when browsing a website (as opposed to a separate Settings page, where three states are fine).<br>E.g. on a documentation site, they may be there to look something up.<br>On a landing page, they may be trying to evaluate whether the product is suitable for their needs.

On a media site, they may be there to read the news.

On a graphics app, they want to draw something.

One thing is for certain: tweaking the theme is not their primary goal [2]This is about users. Yes, the developers of the site may have a goal of testing the theme, but we optimize UIs for being used, not getting debugged. .<br>To get in the mindset of tweaking the theme, something needs to be off.<br>When things look right, users just move on with their actual goal instead of thinking about the theme.

The tri-state control is solving a largely imaginary user goal that is extremely rare among real users, and does not justify the additional complication and UX friction of a three-state toggle.

Worse, it forces the user to decide between choices that produce no visible difference, breaking the principle of feedback.

Yes, tri-state toggles are common.<br>That doesn’t make them good.<br>This essay explains why, and how to do better.

Tri-state toggles are implementation-driven UI

One of the most common UX mistakes is designing UI around the underlying data model instead of user goals.<br>Good interfaces abstract away the underlying model and expose a model that aligns with user goals (unless of course these happen to coincide, which is rare).

The user goal here is to set a specific flow and temperature.<br>The underlying model works with amounts of hot and cold water.<br>Guess which faucet is easier to use?

This is exactly the case with tri-state dark mode toggles; exposing all three states is data model leaking into the UI.

Yes, there should absolutely be three states in the underlying implementation!<br>But at any given point, one of them is irrelevant to the end-user.

Users cannot meaningfully express intent about problems they don’t currently have.

A dark mode toggle is a temporary comfort adjustment .<br>When it comes to user goals, there are only two real states:

The website looks ok. The user moves on with their actual goal and doesn’t look for the toggle at all.

The website is too bright or too dark to be comfortable. The user wants to fix it.

You’re reading in bed, the page is a flashbang, you hit the toggle.<br>You’re on a laptop outside and the dark theme is unreadable in sunlight, you hit the toggle.<br>It’s situational, it’s immediate, and it’s usually about the environment you’re in rather than a considered long-term stance on color schemes.

A third state assumes a usage scenario where a user visits a website that looks perfectly fine, and still looks for a dark mode toggle to ensure it can continue to look fine in the future.<br>Users do all sorts of weird things, so I won’t assert that this never happens, but it is not a natural user interaction, fueled by a real user goal.<br>Even the...