Checkbox vs switch
A switch applies the moment someone flips it. A checkbox waits for a save or submit button. Ask which one your interface is doing, and the decision is already made.
The rule
Every other difference between these two, the shape, the animation, the copy, follows from one thing: when does the change take effect? A switch is a light fixture. Flip it and the room changes right there. A checkbox is a form field. Ticking it records an intention that only becomes real once someone presses save or submit. Get the timing right and the right control follows on its own.
Side by side
| Checkbox | Switch | |
|---|---|---|
| Change applies | On save or submit | Immediately, no save step |
| Can be indeterminate | Yes, for a parent controlling a group | No, only on or off |
| Typical count on screen | Often several, grouped under one label | Usually one, standalone in a settings row |
| Undo path | Uncheck it before saving, nothing happened yet | Flip it back, the change already applied and has to be reverted |
| ARIA role | checkbox | switch |
| Keyboard | Space toggles it, Tab moves on | Space or Enter toggles it, Tab moves on |
| Common home | A form, a filter panel, a table row | A settings screen, a preference list |
GitHub's repository visibility setting is a switch for exactly this reason. Flip a repository from private to public and it's public, right there, no separate confirm step past the warning dialog for a destructive change. A file browser's multi-select checkboxes work the opposite way. Ticking three files doesn't move or delete anything by itself. It just marks a selection that a separate button, "Move" or "Delete," acts on afterward. Neither product could swap its control for the other without the behaviour becoming confusing.
Use a checkbox when
Reach for it wherever the interface needs to collect a choice before doing anything with it.
- Someone can pick several options from a list, or none of them, before confirming the whole form
- The setting is one part of a larger submission, not a standalone action
- A parent option needs a mixed, indeterminate state for a partly-selected group
Use a switch when
Reach for it wherever the click and the consequence are the same event.
- The setting is independent of everything else on the screen and takes effect on its own
- You can revert the change instantly if the request that saves it fails
- There's exactly one on/off state, with nothing in between
Where people get it wrong
The mistake runs in both directions, and both versions are common. A settings screen full of checkboxes that each need their own explicit save button, so someone flips six options and has to remember there's a "Save preferences" button at the bottom they might not scroll to. And the reverse: a form that uses switches for a set of options that are only supposed to apply once the whole form is submitted, so the interface implies six things already happened when in fact nothing has.
There's a smaller version of the same mistake inside forms that mix the two correctly at the field level but get the group wrong. A parent checkbox controlling five children needs the indeterminate state the moment some but not all of them are ticked. Building that with switches doesn't work at all, because a switch only ever has two states and has nowhere to put "some."
Being on a settings screen doesn't automatically mean a switch. Being inside a <form> tag doesn't automatically mean a checkbox. The only question that matters is what happens the instant someone interacts with the control. If the answer is "nothing yet," it's a checkbox. If the answer is "that thing, right now," it's a switch.
A quick way to check your own interface: cover the save button with your hand. If the setting still makes sense as changed, it was never waiting on that button, and it should have been a switch from the start.
Last reviewed 30 JUL 2026