Prepared Docs

Prepared Docs

⌘K

    Loading navigation…

User

  1. Components
  2. Switch
  3. Usage

Switch

Usage

Overview

Switch conveys an on/off state that applies immediately—feature toggles, availability, notification preferences. The control reads as a physical toggle rather than a form input; pair it with sentences that describe what gets enabled, not abstract nouns alone. The mental model is "flip this setting now"—different from a checkbox (submitted later) and from a button (fires a discrete action).

When to use

  • Binary settings with immediate effect, no separate submit step required.
  • Mobile-friendly toggles where a checkbox affordance feels out of place on a settings row.
  • Preferences where the off state is as meaningful as on ("Mute alerts", "Pause auto-acknowledgment").

When not to use

  • Multi-select lists—use Checkbox.
  • Non-binary choices—use SegmentedControl or Select.
  • Destructive actions that should be confirmed—use a Button plus Modal, not a switch.
  • Ephemeral form state that needs to be saved separately—use a checkbox that submits with the form.

Content guidelines

  • Labels describe the enabled state positively ("Enable radio logging"). Localize with formatMessage.
  • Helper text explains side effects or dependencies ("Requires supervisor approval to disable"). The consequence belongs next to the switch, not in a footnote.
  • Keep labels parallel across a settings page so the switches read as peers.

Behavior and states

  • Controlled vs. uncontrolled. Follow form architecture. For switches that hit the network, show optimistic state and roll back on failure with a Snackbar or inline Callout.
  • Loading. Debounce consecutive toggles so the network doesn't thrash. For slow requests, show in-control progress rather than locking the UI.
  • Disabled. Surface the reason in helper text. Silence is the wrong signal on a settings page.

Best practices

Do

  • Align switches vertically on settings pages for fast top-to-bottom scanning.
  • Confirm destructive disables with a modal when the mistake impact is high.
  • Keep the pressed visual legible in both themes.

Don't

  • Place irreversible switches without a confirmation step when a misclick would cause harm.
  • Duplicate the same switch at multiple navigation levels without a sync guarantee. Operators toggle the nearest one and assume the others followed.
  • Use switches as data-table row controls when space is tight—prefer a checkbox column that submits with an action.

Accessibility

Switch exposes on/off state to assistive technology; the label toggles the control; focus rings are visible in both themes. See Accessibility for the full contract.

Related Components

  • Checkbox for non-immediate multi-select forms.
  • Segmented control for multi-mode switches.
  • Callout for communicating side effects of a toggle.
  • Label for label conventions.

Previous

Status dot / Accessibility

Next

Switch / API and Development

On this page

Overview
When to use
When not to use
Content guidelines
Behavior and states
Best practices
Accessibility
Related Components