Meter vs Progress bar vs Slider vs Spinbutton / numeric stepper

Choose meter when the value already exists, is read-only in this context, has a meaningful minimum and maximum, and users need to judge whether it is low, normal, high, safe, risky, full, or depleted.

Meter live example Progress bar live example Slider live example Spinbutton / numeric stepper live example

Decision dimensions

Dimension	Meter	Progress bar	Slider	Spinbutton / numeric stepper
UI or UX	UI + UX - Read-only scalar value gauge within a known range	UI + UX - Measurable system-operation progress indicator	UI + UX - Single-value bounded range control	UI + UX - Bounded incrementable numeric-value control
UI guidance	Show the measured object, current value, unit, minimum and maximum context, and threshold bands close to the gauge so users can interpret the reading without guessing.	Show a labeled bar with a track, filled value, and nearby helper text that reports the measurable unit such as percent, bytes, rows, files, records, or stages.	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 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 meter when users need to judge the current level of a bounded resource, score, capacity, or risk, not when they are completing a task or choosing a value.	Use a progress bar when the system can honestly report movement toward a known finish and users need to decide whether to wait, cancel, retry, continue elsewhere, or return later.	Help users adjust one bounded value quickly when the relative position or intensity matters.	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	An account storage card says 86 GB of 100 GB used, marks 70 GB as warning and 90 GB as critical, and labels the current state Critical.	A document upload card says Uploading evidence.zip, shows 64%, 32 of 50 MB, a Cancel action, and keeps the rest of the form usable.	A Brightness slider shows 55%, dim and bright endpoint labels, visible focus, and a paired number input.	A Guests control shows label, value 2, minus and plus buttons, range 0 to 9, and a clear unit beside the field.
Bad UI	A red-to-green bar says 89% with no unit, minimum, maximum, or explanation of whether high is good.	A blue bar fills across the top of the page with no label, no percent, and no affected object.	An unlabeled rail has no visible value, min, max, or unit.	An account ID field has plus and minus buttons, implying the identifier can be stepped.
Good UX	A user sees storage at 86 of 100 GB, understands the account is in the critical band, opens Manage storage, and deletes old exports before uploads are blocked.	A user uploads evidence.zip, sees progress move from 12% to 64%, cancels before commit, retries after a network error, and gets a completed receipt only after server processing succeeds.	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 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 watches a meter animate during upload and waits for it to reach full even though it represents remaining quota, not upload progress.	A fake progress bar inches to 99% for minutes with no elapsed time, cancel, retry, or background option.	A user tries to enter $812.37 with a huge slider and cannot land on the exact cents.	A user tries to set 480 items with one-step buttons and cannot type or jump by larger increments.
Best fit	A current value exists inside a meaningful known range.	A system operation has a measurable total or bounded progress value.	Users adjust one bounded value such as brightness, volume, opacity, zoom, intensity, cost tolerance, or preference strength.	Users adjust a small bounded count such as guests, copies, items, seats, nights, minutes, retries, or quantity.
Avoid when	The value has no meaningful maximum or minimum.	Progress cannot be measured or would be guessed.	Users need to enter an exact, arbitrary, or high-stakes number.	The value is a numeric-looking identifier, code, account number, card number, phone number, postal code, date, or formatted string.
Required state	Normal state inside the acceptable band.	Idle state before the operation starts.	Initial value state with visible label, min, max, current value, and unit.	Initial state with visible label, default value, unit, min, max, and step.
Accessibility burden	Prefer the native meter element where possible because it carries the correct read-only meter semantics.	Provide an accessible name that identifies the operation and affected object.	Prefer native range input where possible.	Expose the editable value as a spinbutton or native number input with a visible label.
Common misuse	Using a meter to show task progress such as upload completion.	Fabricating progress values just to make users feel movement.	Using a slider for a binary on/off choice.	Using a spinbutton for numeric-looking identifiers or codes.

Meter

UI or UX: UI + UX - Read-only scalar value gauge within a known range
UI guidance: Show the measured object, current value, unit, minimum and maximum context, and threshold bands close to the gauge so users can interpret the reading without guessing.
UX guidance: Use a meter when users need to judge the current level of a bounded resource, score, capacity, or risk, not when they are completing a task or choosing a value.
Good UI: An account storage card says 86 GB of 100 GB used, marks 70 GB as warning and 90 GB as critical, and labels the current state Critical.
Bad UI: A red-to-green bar says 89% with no unit, minimum, maximum, or explanation of whether high is good.
Good UX: A user sees storage at 86 of 100 GB, understands the account is in the critical band, opens Manage storage, and deletes old exports before uploads are blocked.
Bad UX: A user watches a meter animate during upload and waits for it to reach full even though it represents remaining quota, not upload progress.
Best fit: A current value exists inside a meaningful known range.
Avoid when: The value has no meaningful maximum or minimum.
Required state: Normal state inside the acceptable band.
Accessibility burden: Prefer the native meter element where possible because it carries the correct read-only meter semantics.
Common misuse: Using a meter to show task progress such as upload completion.

Progress bar

UI or UX: UI + UX - Measurable system-operation progress indicator
UI guidance: Show a labeled bar with a track, filled value, and nearby helper text that reports the measurable unit such as percent, bytes, rows, files, records, or stages.
UX guidance: Use a progress bar when the system can honestly report movement toward a known finish and users need to decide whether to wait, cancel, retry, continue elsewhere, or return later.
Good UI: A document upload card says Uploading evidence.zip, shows 64%, 32 of 50 MB, a Cancel action, and keeps the rest of the form usable.
Bad UI: A blue bar fills across the top of the page with no label, no percent, and no affected object.
Good UX: A user uploads evidence.zip, sees progress move from 12% to 64%, cancels before commit, retries after a network error, and gets a completed receipt only after server processing succeeds.
Bad UX: A fake progress bar inches to 99% for minutes with no elapsed time, cancel, retry, or background option.
Best fit: A system operation has a measurable total or bounded progress value.
Avoid when: Progress cannot be measured or would be guessed.
Required state: Idle state before the operation starts.
Accessibility burden: Provide an accessible name that identifies the operation and affected object.
Common misuse: Fabricating progress values just to make users feel movement.

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.

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.

Decision rules

Choose meter when the value already exists, is read-only in this context, has a meaningful minimum and maximum, and users need to judge whether it is low, normal, high, safe, risky, full, or depleted.
Choose progress bar when the value represents completion of an active task such as upload, download, validation, processing, or import that moves toward a finish.
Choose slider when the user is choosing or adjusting one value across a range and relative thumb position is the interaction.
Choose spinbutton when the user must enter or step a small bounded numeric value such as guests, copies, seats, nights, minutes, or quantity.
Do not use meter for values without a meaningful maximum such as total users, world population, revenue to date, or all-time requests.
Do not make a meter interactive; if the user can change the value, use the input control that matches the task.
Use low, high, and optimum thresholds only when the bands have product meaning, and label those bands so color is not the only cue.
Use value text when a raw percent is not enough, such as 86 GB of 100 GB used, 50% battery and 6 hours remaining, or credit utilization in the risk zone.

Inspect live examples

Meter Progress bar Slider Spinbutton / numeric stepper

Failure modes

A storage meter is used as a progress bar while files upload, so users think capacity is changing because the upload is completing.
A CPU usage meter has no maximum, threshold labels, or current units, so the bar is only decoration.
A meter is styled with a draggable thumb even though it is read-only.
A quota gauge relies on red, yellow, and green only, leaving users who cannot perceive color without threshold meaning.
A meter shows 89% risk without explaining whether high is good, bad, or neutral.
An account ID or transaction number is shown as a meter because it is numeric, even though it is not a scalar measurement.