Implement a Theme Toggle That Persists Choice and Respects prefers-color-scheme

Q: Implement a Theme Toggle That Persists Choice and Respects prefers-color-scheme

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Easy > **How to read this doc:** every claim about this session's real browser environment — including which theme the OS genuinely prefers — was checked live via `window.matchMedia`, not assumed. ## 1. The problem, restated Determine the initial theme by checking a persisted, explicit user choice first; if none exists, fall back to the real OS-level `prefers-color-scheme` media query. Once the user makes an explicit choice, persist and honor it on every future load, until it is cleared. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Live-update if OS preference changes mid-session with no explicit choice made? | A real, common enhancement — `matchMedia`'s own `change` event supports this directly. | | `localStorage` vs. a cookie? | A cookie is readable server-side before first paint (avoiding a flash of the wrong theme on an SSR

The problem

Problem, as an interviewer would state it: "Build a light/dark theme toggle. Before the user has ever made a choice, it should default to their operating system's preference. Once they explicitly pick a theme, that choice should persist and win over the system preference on every future visit — until they clear it, at which point it should go back to following the system preference again."

Examples:

Code

// no stored choice, OS prefers dark -> theme is "dark"
// user clicks "light" -> theme is "light", persisted
// page reloads -> theme is STILL "light" (the stored choice, not the OS preference)

Clarifying questions expected:

Should the theme also update live if the OS preference changes WHILE the page is open and the user hasn't made an explicit choice yet?
Where should the choice persist — localStorage, a cookie (for server-rendered pages to know the theme before first paint), or either is fine?
Is "system" itself a selectable third option (explicitly "follow the OS", distinct from "no choice made yet")?

Code / implementation expected: Yes — real, live proof against this session's own actual browser: the real OS-level preference is read correctly, an explicit choice correctly persists and survives a simulated reload, and clearing that choice correctly falls back to the system preference again.

css
media-query
localstorage

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Easy

How to read this doc: every claim about this session's real browser environment — including which theme the OS genuinely prefers — was checked live via window.matchMedia, not assumed.

1. The problem, restated

Determine the initial theme by checking a persisted, explicit user choice first; if none exists, fall back to the real OS-level prefers-color-scheme media query. Once the user makes an explicit choice, persist and honor it on every future load, until it is cleared.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Live-update if OS preference changes mid-session with no explicit choice made?	A real, common enhancement — `matchMedia`'s own `change` event supports this directly.
`localStorage` vs. a cookie?

The solution is hidden so you can try first

6 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, live-verified proof against this session's actual browser: correctly reads the real OS preference, persists an explicit choice across a simulated reload, and reverts on clear