Spinbutton / numeric stepper vs Slider vs Text input vs Select

Prefer a spinbutton when the value is truly incrementable, bounded, and likely to change by a few steps, such as guests, copies, seats, nights, items, minutes, or retry count.

Spinbutton / numeric stepper live example Slider live example Text input live example Select live example

Decision dimensions

Dimension	Spinbutton / numeric stepper	Slider	Text input	Select
UI or UX	UI + UX - Bounded incrementable numeric-value control	UI + UX - Single-value bounded range control	UI + UX - Single-line freeform data-entry control	UI + UX - Single-choice dropdown control
UI guidance	Render a visible label, editable numeric value, unit, lower and upper bounds, plus and minus controls, focus state, and warning, error, disabled, and read-only states.	Render one thumb on a track with a persistent label, visible current value, unit, min and max labels, focus state, and disabled or read-only state.	Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.	Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.
UX guidance	Use a spinbutton when users adjust a small count or bounded quantity by one or a few steps and still may need to type the exact number.	Help users adjust one bounded value quickly when the relative position or intensity matters.	Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.	Help users choose one value from a moderate known list without showing every option permanently.
Good UI	A Guests control shows label, value 2, minus and plus buttons, range 0 to 9, and a clear unit beside the field.	A Brightness slider shows 55%, dim and bright endpoint labels, visible focus, and a paired number input.	A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.	Persistent label, hint text, visible selected value, readable options, and clear required validation state.
Bad UI	An account ID field has plus and minus buttons, implying the identifier can be stepped.	An unlabeled rail has no visible value, min, max, or unit.	The only instruction is placeholder text that disappears when the user starts typing.	Placeholder as the only label.
Good UX	A user adds one guest, types 7, clears the required field, then sees a specific error and restores a valid count without losing context.	A user adjusts brightness with arrow keys, types 65 in the number field, sees both controls synchronize, and gets a warning near battery-heavy values.	A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.	Users can open, scan, choose one value, and review the selected value after close.
Bad UX	A user tries to set 480 items with one-step buttons and cannot type or jump by larger increments.	A user tries to enter $812.37 with a huge slider and cannot land on the exact cents.	Validation fires on the first focus event and blocks typing before the user has had a chance to answer.	Hiding two obvious critical choices in a dropdown.
Best fit	Users adjust a small bounded count such as guests, copies, items, seats, nights, minutes, retries, or quantity.	Users adjust one bounded value such as brightness, volume, opacity, zoom, intensity, cost tolerance, or preference strength.	The answer is short and user-authored.	The user chooses one option from a moderate known list.
Avoid when	The value is a numeric-looking identifier, code, account number, card number, phone number, postal code, date, or formatted string.	Users need to enter an exact, arbitrary, or high-stakes number.	The answer is a paragraph, comment, address block, or explanation requiring multiple lines.	The option set is short and comparison matters.
Required state	Initial state with visible label, default value, unit, min, max, and step.	Initial value state with visible label, min, max, current value, and unit.	Empty untouched state with persistent label and optional hint.	Closed state with empty option or current selected value.
Accessibility burden	Expose the editable value as a spinbutton or native number input with a visible label.	Prefer native range input where possible.	Associate every text input with a visible label or equivalent accessible name that matches the visible question.	Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
Common misuse	Using a spinbutton for numeric-looking identifiers or codes.	Using a slider for a binary on/off choice.	Using placeholder text as the only label or instruction.	Custom select with no keyboard support or hidden selected state.

Spinbutton / numeric stepper

UI or UX: UI + UX - Bounded incrementable numeric-value control
UI guidance: Render a visible label, editable numeric value, unit, lower and upper bounds, plus and minus controls, focus state, and warning, error, disabled, and read-only states.
UX guidance: Use a spinbutton when users adjust a small count or bounded quantity by one or a few steps and still may need to type the exact number.
Good UI: A Guests control shows label, value 2, minus and plus buttons, range 0 to 9, and a clear unit beside the field.
Bad UI: An account ID field has plus and minus buttons, implying the identifier can be stepped.
Good UX: A user adds one guest, types 7, clears the required field, then sees a specific error and restores a valid count without losing context.
Bad UX: A user tries to set 480 items with one-step buttons and cannot type or jump by larger increments.
Best fit: Users adjust a small bounded count such as guests, copies, items, seats, nights, minutes, retries, or quantity.
Avoid when: The value is a numeric-looking identifier, code, account number, card number, phone number, postal code, date, or formatted string.
Required state: Initial state with visible label, default value, unit, min, max, and step.
Accessibility burden: Expose the editable value as a spinbutton or native number input with a visible label.
Common misuse: Using a spinbutton for numeric-looking identifiers or codes.

Slider

UI or UX: UI + UX - Single-value bounded range control
UI guidance: Render one thumb on a track with a persistent label, visible current value, unit, min and max labels, focus state, and disabled or read-only state.
UX guidance: Help users adjust one bounded value quickly when the relative position or intensity matters.
Good UI: A Brightness slider shows 55%, dim and bright endpoint labels, visible focus, and a paired number input.
Bad UI: An unlabeled rail has no visible value, min, max, or unit.
Good UX: A user adjusts brightness with arrow keys, types 65 in the number field, sees both controls synchronize, and gets a warning near battery-heavy values.
Bad UX: A user tries to enter $812.37 with a huge slider and cannot land on the exact cents.
Best fit: Users adjust one bounded value such as brightness, volume, opacity, zoom, intensity, cost tolerance, or preference strength.
Avoid when: Users need to enter an exact, arbitrary, or high-stakes number.
Required state: Initial value state with visible label, min, max, current value, and unit.
Accessibility burden: Prefer native range input where possible.
Common misuse: Using a slider for a binary on/off choice.

Text input

UI or UX: UI + UX - Single-line freeform data-entry control
UI guidance: Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field.
UX guidance: Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.
Good UI: A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.
Bad UI: The only instruction is placeholder text that disappears when the user starts typing.
Good UX: A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.
Bad UX: Validation fires on the first focus event and blocks typing before the user has had a chance to answer.
Best fit: The answer is short and user-authored.
Avoid when: The answer is a paragraph, comment, address block, or explanation requiring multiple lines.
Required state: Empty untouched state with persistent label and optional hint.
Accessibility burden: Associate every text input with a visible label or equivalent accessible name that matches the visible question.
Common misuse: Using placeholder text as the only label or instruction.

Select

UI or UX: UI + UX - Single-choice dropdown control
UI guidance: Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.
UX guidance: Help users choose one value from a moderate known list without showing every option permanently.
Good UI: Persistent label, hint text, visible selected value, readable options, and clear required validation state.
Bad UI: Placeholder as the only label.
Good UX: Users can open, scan, choose one value, and review the selected value after close.
Bad UX: Hiding two obvious critical choices in a dropdown.
Best fit: The user chooses one option from a moderate known list.
Avoid when: The option set is short and comparison matters.
Required state: Closed state with empty option or current selected value.
Accessibility burden: Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
Common misuse: Custom select with no keyboard support or hidden selected state.

Decision rules

Prefer a spinbutton when the value is truly incrementable, bounded, and likely to change by a few steps, such as guests, copies, seats, nights, items, minutes, or retry count.
Prefer a slider when users adjust one value across a wider range by spatial position or subjective intensity rather than repeated small clicks.
Prefer text input when users need to type an exact arbitrary value, paste a value, enter decimals or currency, use a very large range, or provide a number that is really an identifier.
Prefer select when valid values are named options or a short fixed list where users benefit from seeing labels before choosing.
Do not use a spinbutton for account numbers, payment card numbers, verification codes, ZIP or postal codes, phone numbers, dates, or other numeric-looking strings that should not increment.
Keep a direct editable value field available unless the surrounding platform convention makes button-only stepping clearly sufficient.
Declare min, max, step, unit, default, empty state, disabled state, read-only state, and repair or validation feedback near the control.
Use arrow keys for one-step movement and Home, End, Page Up, and Page Down only when the range and larger-step behavior are clear.
Disable the decrement button at the lower bound and the increment button at the upper bound, but keep the reason visible when the whole field is unavailable.
When the value is high-stakes or expensive to change, confirm through review or clear submit behavior instead of silently committing each click.

Inspect live examples

Spinbutton / numeric stepper Slider Text input Select

Failure modes

A customer ID is rendered with plus and minus buttons, so keyboard arrows can change the identifier.
A quantity from 1 to 500 requires hundreds of clicks because no direct typing or larger-step path exists.
The current number has no unit or label, so users cannot tell whether they are changing rooms, guests, nights, or items.
The field accepts decimals while the buttons move by whole units and the submitted value is rounded without warning.
A sold-out value is disabled without an explanation or read-only review path.
The plus and minus buttons are focusable but have names like plus and minus instead of the affected quantity.

Sources

WAI-ARIA APG Spinbutton Pattern
APG defines discrete spinbutton values, direct editing, increase and decrease behavior, arrow keys, Home, End, optional Page keys, value attributes, labeling, and invalid state.
Carbon Design System Number Input
Carbon defines number input as a numeric field with increase and decrease controls, recommends it for small incremental changes, and points to slider or text input for large ranges and exact wide-range values.
React Spectrum NumberField
React Spectrum documents labels, min and max clamping, step values, stepper buttons, raw numeric submission, units, percentages, and currency formatting.
MDN input type number
MDN documents min, max, step, required, automatic numeric invalidation, unsupported pattern matching, and server-side validation needs for number inputs.
GOV.UK Design System numeric text-input guidance
GOV.UK cautions against input type number without research, distinguishes numeric strings from incrementable numbers, and documents specific numeric error wording.

Verification

Last verified: 2026-06-09