Checkbox

Paper forms already had little squares. Tick the ones that apply, and whether you could tick more than one was explained in a line of text printed beside them. The structure relied on the reader reading a sentence and deciding.

That stopped working once forms moved onto screens. People don't read the instruction line; they click first. In a place where several answers are allowed they pick one and move on, or in a place where only one is allowed they click twice and come back confused about why the first choice released. Submit with the wrong state and notification settings are switched off entirely, or the next screen loads with a required agreement unticked.

So the shape itself was made to carry the rule. A square means you can pick more than one. A circle means you can pick exactly one. Because that convention held, people know what's allowed from the shape before they read anything. It's also why checkboxes are still square — change the shape and the promise breaks.

The defining behavior is that each box turns on and off on its own. With three kinds of notification, you can have all three, two, or none. Clicking one never releases another. That is exactly where it parts from the radio button, which allows one choice per group.

There are three states.

1. Checked — selected, with a mark inside the square.
2. Unchecked — not selected, left as an empty square. Greying it out instead makes it read as disabled.
3. Indeterminate — used when only some of the items underneath are checked, drawn as a dash rather than a mark. The select-all box at the top of a table, which lays data out in rows and columns, is the classic case. If that box reads as checked while 7 of 20 rows are selected, someone will hit delete believing all 20 are going.

When the value actually takes effect is a separate decision. A checkbox belongs where changes apply together once a save button is pressed. Nothing happening on click isn't a bug — collecting several choices and sending them in one go is the premise of the control. For settings that must apply the instant they're pressed, use a toggle.

The clickable area is part of the design too. The square itself is around 20 pixels on a side, which fingers miss constantly. Extend the target to cover the label text beside it and the area grows close to tenfold. From a keyboard, people tab to it and press space. Draw the square as an image and hide the underlying element and that behavior disappears, leaving anyone who can't use a mouse with no way to choose at all. Accessibility — designing so the product works regardless of disability or circumstance — tends to break in exactly this small a component.

The most familiar spot is the terms agreement on a signup screen, and here a single box on its own is common. A control built for multiple selection gets used alone because the task really is picking one of two states, on or off. Group required and optional agreements together with an accept-all box above them, and that top box lands in the indeterminate state whenever only some of the items below are checked.

The second is selecting several rows to act on at once. Picking twelve documents from a list to move into a folder or delete belongs here. In that case the count of selected items has to appear somewhere on screen. Scrolling hides what was checked higher up, so without a number the user presses the button without knowing how many things are about to go.

The third is narrowing results. Checkboxes beside a search result let several conditions stack at the same time. Unlike a select, which takes one value from a fixed list, this control can hold two or more conditions simultaneously, which is why it lives here. Past about ten options the column grows long, so teams add a search field above it or show the frequent ones and collapse the rest.

"This should be a toggle, not a checkbox. There's no save button on this screen."

Sort the controls by whether the change applies immediately.

"Select-all isn't drawing the indeterminate state, so you can't tell how many are picked."

The state that represents a partial selection is missing.

"Make the label clickable. Right now only the square responds and we keep missing it on mobile."

The hit area is too small and real use is failing because of it.

At Pagedeck this came up while adding bulk delete to the document list. Noa put a checkbox on every row with a select-all box at the top, and in the first pass that top box had only two states, checked and unchecked. With three rows selected it was still an empty square.

Theo found the problem during implementation: 50 rows show per page, so a user who checks three and scrolls down sees no indication at all. Noa added the indeterminate state and a line above the list reading "3 selected." Mia asked for the same number on the delete button, on the grounds that an irreversible action deserves one more look at the count.

The most common mistake is treating checkbox versus toggle as a matter of taste. Both switch something on and off, so it feels reasonable to pick whichever suits the layout. What actually separates them is not the shape but when the change lands. A toggle changes the value the moment it's pressed; a checkbox waits for save. Mix them and someone switches a setting on, can't find a save button, leaves, comes back to find it off, and files a bug report about a broken feature.

The other is seeing it as a component where only the visuals matter. A square with a tick in it looks finished, which is why it tends to be the first thing drawn in a design system and the least reviewed. But this control carries a hit area, keyboard handling, an indeterminate state, and the name a screen reader announces. Miss any one of them and the same defect gets copied into every screen that uses the component. Fix it after it has spread to twenty screens and there are twenty places to check.