Checkbox

A click anywhere on the BitCheckbox - the box or its label - toggles it. Left unbound like the first one below, it keeps its own state with no binding or event handler involved, and DefaultValue only picks where that state starts. Title fills the native tooltip shown on hover. Disabling the BitCheckbox greys it out and takes it out of the interaction; the disabled state renders both checked and unchecked.

Each state of the BitCheckbox can render its own icon: CheckIconName replaces the check mark of the checked state, UncheckedIconName puts an always-visible icon in the otherwise empty unchecked box - which by default only previews the check mark on hover - and IndeterminateIconName replaces the filled square of the indeterminate state. For icons from external libraries, the External Icons section shows the BitIconInfo counterparts of these parameters.

Reversed swaps the two sides, putting the label before the box - the usual layout when the BitCheckbox sits at the end of a settings row. It is the single-flag shorthand of the more general LabelPosition parameter demonstrated in the next section.

LabelPosition places the label on any of the four sides of the box: End is the default reading order, Start matches what Reversed does, and Top and Bottom stack the label above or below - handy in dense toolbars and table headers. Wherever the label sits, it stays part of the click target. It takes precedence over Reversed when both are set.

When a plain string is not enough - a formatted phrase, a tag, a link to the terms being agreed to - LabelTemplate replaces the label with arbitrary markup while the box, the toggle behavior and the click target all stay intact.

Indeterminate renders the third visual state - a filled square meaning "partially" - which takes visual precedence over the checked state without touching the underlying Value. It is a display-only state: the first click clears it and toggles the value, and only code can set it again (unless ThreeState makes it part of the cycle), while DefaultIndeterminate merely starts it there in uncontrolled mode. Screen readers announce it as mixed.

The classic home of the indeterminate state is a select-all checkbox that reflects a partially selected list: checked when every item is, unchecked when none is, and indeterminate in between.

By default the indeterminate state is only reachable programmatically and the user can merely leave it. ThreeState makes it part of the interaction instead: each click cycles the BitCheckbox through unchecked, checked and indeterminate, for answers that are genuinely three-valued - yes, no, and no answer.

Value: False, Indeterminate: False

Both Value and Indeterminate come in the usual binding shapes. Passed one-way, the parameter dictates the state: the BitCheckbox renders whatever the expression says and clicks cannot move it away from a fixed value. Bound two-way with @bind-Value or @bind-Indeterminate, changes flow in both directions - clicks update the field, and updating the field from elsewhere (the toggle buttons below) updates the BitCheckbox.

Value:

Indeterminate:

Three callbacks fire in a fixed order around a click: OnClick first, while the state is still the old one; then OnChanging, carrying the state the BitCheckbox is about to move to; and finally OnChange, once the new state is committed. The checkbox below has all three wired to a log - click it and watch the order:

No clicks yet.

OnChanging is the veto point: setting Cancel on its arguments leaves the BitCheckbox where it was, so a change can be refused instead of silently reverted afterwards. It is awaited, so it can take its time - asking for confirmation, or checking with the server before letting the state through.

Cancelled attempts: 0

A BitCheckbox inside a clickable container fires that container's handler too - twice, in fact, since the label click and the click it forwards to the input both bubble. StopPropagation keeps the clicks to itself. Both checkboxes below sit in the same clickable box:

Container clicks: 0

ReadOnly keeps the BitCheckbox focusable and lets screen readers announce it, but clicking or pressing Space no longer changes it - unlike disabling, which takes it out of the interaction entirely. The value can still change programmatically:

Required renders the native required attribute on the checkbox input and marks the label with an asterisk:

Inside an EditForm, the BitCheckbox takes part in validation like any other input: bind it to a model property, let data annotations state the rule - here, that the terms must be agreed to - and a failed submit shows the message. While invalid, the BitCheckbox also switches to its error styling and renders aria-invalid, so the failure is visible and announced right at the control.

ChildContent goes one step beyond LabelTemplate and replaces the box and the label together: whatever markup you put inside the BitCheckbox becomes its face, while the clicking, the binding and the keyboard behavior keep working underneath. The content is on its own to reflect the state - here by deriving the icon from the bound values.

The BitCheckbox is backed by a real, focusable checkbox input: Tab moves the focus to it - drawing a focus ring around the box - Space toggles it, and screen readers announce it as a checkbox, reading the indeterminate state as mixed. AutoFocus puts the initial focus on it when the page renders.

The FocusAsync method moves the focus programmatically:

A BitCheckbox without a visible label needs an AriaLabel to have an accessible name, and AriaDescription adds a visually hidden description that screen readers read after the name:

When a visible element already labels the checkbox, AriaLabelledby points at it instead of repeating the wording in an AriaLabel that could drift out of sync with it:

In a list that only shows a fragment of a larger set - a virtualized or paged list - AriaSetSize and AriaPositionInSet tell assistive technologies the real size of the set and where each checkbox sits in it:

Color picks the theme color the checked box and the indeterminate square fill with, with Primary as the default. The semantic colors - Success, Warning, Error and friends - tie the BitCheckbox to what agreeing to it means, while the Background, Foreground and Border families keep it legible on non-default surfaces like the inverted panel below. Each color is shown in all three states.

The per-state icons are not limited to the built-in icon font: CheckIcon, UncheckedIcon and IndeterminateIcon take a BitIconInfo - or a raw CSS class string - that can point at any icon library whose stylesheet is loaded, like FontAwesome or Bootstrap Icons below. Use BitIconInfo.Fa(), BitIconInfo.Bi() or BitIconInfo.Css() to build one.

FontAwesome:

Bootstrap Icons:

Size scales the box, its icon and the label together: Small for dense lists and table rows, Medium (the default) for forms, and Large where the BitCheckbox is a primary control or aimed at touch. Each size is shown in all three states.

Style and Class land on the root element, which inline styles and a single class cover well. For anything deeper, Styles and Classes reach the individual parts - box, icon, label, container - and their Checked and Indeterminate entries apply only while the BitCheckbox is in that state, which is how the examples below restyle the checked look without touching the unchecked one.

Component's Style & Class:

Styles & Classes:

Setting Dir to BitDir.Rtl mirrors the whole layout for right-to-left languages: the box moves to the right of the label and the spacing follows, so the BitCheckbox reads naturally inside an RTL page like the Farsi examples below.