Toggle

Settings screens spent years as a column of checkboxes with a save button at the bottom. In a document editor that button is a familiar device, but on a screen where someone changes one value and leaves, it acts as one more piece of homework. The two kinds of screen look alike and behave differently, and that is where the mismatch starts.

Pagedeck's notification settings worked that way. Six boxes and a save button. When Noa went through the records, 23 percent of the visits that touched a setting left without pressing save. Some of them wrote in the following week asking why notifications kept arriving after they had turned them off. The user remembered changing it and the product had not changed. Nothing on the screen indicated that the change was unsaved.

A toggle brings the shape of a wall switch onto the screen. On a switch, the act of flipping it and the light coming on are not two separate events. Borrowing that property — the operation is the effect — is how this element removed the save step.

Pressing it moves between the two states immediately and the result is stored right there. Seven things get decided.

1. There are exactly two states. No half-on, no not-yet-chosen. If three are needed, this is the wrong element, and so is a value that requires an intermediate step to turn on.
2. Show the current state through shape. Use the knob position along with the color. Color alone makes both states look identical to someone who can't distinguish them. Being readable at a glance is the whole point of the shape; a state that needs a second look defeats it.
3. Label the subject, not the state. Write "Email notifications" and let the switch carry on and off. Write "Turn off notifications" and a switch in the on position could mean either.
4. Apply it to the screen and to the server the moment it is pressed. From the instant users see this element they stop looking for a save button, so a failed write splits what they believe from what is stored. This is the cost of removing the save button: the element now owns the write, and every failure path that comes with it.
5. If the write takes time, move the knob first and overlay a progress indicator. On failure, return the knob and say why. Skip the return and the screen alone stays switched on.
6. Give the knob a short movement. A micro-interaction under about 0.2 seconds reports that the state just changed. With color changing and nothing moving, whether the press registered stays unclear.
7. Make it work with a keyboard and a screen reader. It should take focus, respond to the space key, and expose its current state the way ARIA prescribes, so someone not looking at the screen still knows whether it's on. Announcing it as a switch rather than a checkbox is part of that.

Use it on screens with no save button. Whether to receive notifications, whether a document is public by link, whether to view the interface in dark colors — settings where one value changes and the person leaves. Being able to press again and undo is what makes immediate application affordable. The same logic explains why toggles cluster in preference panels and almost never appear in a signup flow.

Three places it doesn't fit.

1. Inside a form with a submit button. Use a checkbox there. A form only sends values on submit, which breaks the premise of immediate effect. Agreeing to terms is a checkbox for the same reason.
2. When there are three or more options. If it isn't one of two, spread them out as radio buttons or fold them into a select. Three toggles wired so only one can be on hides the rule from the screen, leaving users to discover it by pressing.
3. Actions that are hard to undo. Deleting an account or canceling a subscription doesn't happen on one press. Put a confirmation step there and keep toggles for reversible settings. A press that can't be taken back is a decision, and decisions get a dialog.

With several on one screen, give each its own row and fix the layout — label left, switch right. Past about eight, break them up under group headings. A screen with twenty switches makes people count what they left on, and when the gap between label and switch grows, pairing them by eye gets harder.

"Let's use a toggle here. This screen applies changes without a save button."

Whether the change takes effect immediately is the test for choosing this element.

"If the label says 'turn off notifications,' an on switch could mean either. Change it to the subject."

A negative label plus a state indicator inverts the meaning.

"The write takes two seconds, so move the knob first and roll it back if it fails."

Deciding how to handle the window where screen and server disagree.

Noa replaced the six checkboxes in notification settings with switches and removed the save button. The 23 percent who left without saving disappeared outright, because an unsaved state no longer existed.

A new problem arrived instead. When the write to the server failed, the switch on screen stayed on. Users believed they had turned something off while notifications kept going, and it was harder to notice than under the old design. The failure was silent on both sides, which is the worst combination a settings screen can have. Noa and Theo changed it to return the knob to its original position and show a short reason. The promise of immediate effect doesn't hold unless what to show on a failed write is decided too.

The most common reading is that this is a better-looking checkbox. Both take an on-or-off value, so the difference looks cosmetic. What separates them is when the value is stored. Put a switch inside a form with a submit button and users assume it's already saved and never press submit. That's how a cleanup pass that swaps form checkboxes for switches ends up raising the rate of abandoned forms. Neither element is more modern than the other; they answer different questions about timing.

Reading an on switch as something the user turned on is the other one, since on looks like a choice. But an item on by default was never chosen by anyone. Leave marketing email on by default and treat that as consent, and there is no evidence to point to later. A default is a value that has to be decided and recorded separately; the switch being on proves nothing. Recording who changed it and when is what turns a state into evidence.