The <meter> Element

Basic

What <meter> represents

The <meter> element represents a scalar measurement within a known range, or a fractional value. It is a gauge: the value tells the user where a measurement currently sits within meaningful bounds.

<? min="0" max="100" value="72">72%</meter>

<meter> is not <progress>

Use <meter> for a measurement or gauge such as disk usage, a score, or relevance. Use <progress> when the value describes completion of a task. The visual resemblance does not change the semantics.

<meter> is not <output>

Use <output> for a result produced by a calculation or user action. Use <meter> when the value itself is a meaningful position within a known range.

Basic syntax

A basic meter can be written as <meter min="0" max="100" value="72">72%</meter>. The fallback content is useful text, but the machine-readable gauge state comes from the element attributes and DOM properties.

<label for="storage">Storage used</label>
<meter id="storage" min="0" max="100" value="72">72%</meter>

Start with the smallest useful model: give the meter a known range, provide the current value, and include readable fallback text inside the element.

See the thresholds in action

The range alone tells you where the measurement sits. Add low, high, and optimum when the meaning of the measurement depends on preferred and less-preferred regions.

<label for="battery">Battery</label>
<meter id="battery" min="0" max="100" low="20" high="80" optimum="90" value="35">35%</meter>

Make a meter respond to data

A meter becomes especially useful when its value represents live application state. Keep the measurement model in JavaScript, then update the element's value instead of rebuilding the markup.

The value attribute

value is the current measured value. If it is missing or malformed, the element uses its default value. A value outside the defined range is clamped to the nearest valid endpoint.

The min attribute

min defines the lower bound of the measured range. If omitted, the minimum is 0. The lower bound must remain below the maximum bound.

The max attribute

max defines the upper bound. If omitted, the maximum is 1. A meter therefore works naturally with fractions as well as explicit application ranges.

The effective range

The effective range is determined by min and max. Authors should choose bounds that represent the real measurement rather than merely making the bar look convenient.

Fractional values

A fractional measurement can be represented naturally when the meaningful range is 0 to 1. For example, value="0.82" can represent an 82% fraction without pretending the underlying measurement is an arbitrary 0–100 score.

The low threshold

low identifies the upper boundary of the low portion of the range. It is meaningful only relative to the minimum, high, and maximum boundaries.

The high threshold

high identifies the lower boundary of the high portion of the range. It works with low and the range endpoints to divide the gauge into semantic regions.

The optimum value

optimum indicates which value is considered preferable. It gives the user agent enough information to determine whether lower, middle, or higher values are preferable when low and high are also supplied.

Threshold ordering rules

The low, high, and optimum values are not independent decoration. They have relationships to min and max, and invalid or out-of-order values are normalized by the element algorithms.

Low, normal, and high regions

With low and high thresholds, the range can be understood as lower, middle, and upper regions. The optimum value tells the browser which direction is desirable; this is why a high number is not universally “better.”

When lower is better

If optimum is in the lower part of the range, values near the minimum are preferable. A battery charge example is different from a CPU-temperature example, so authors must model the meaning rather than assume a universal color convention.

When the middle is better

An optimum in the middle indicates that neither extreme is desirable. This is useful for measurements where a target band is preferable to either a low or high value.

When higher is better

An optimum in the upper part indicates that larger values are preferable. A score or completion-like measurement can sometimes use this pattern, provided the concept is a measurement rather than task progress.

Labeling the meter

A meter is labelable content. Give it a clear accessible name using an associated label or another appropriate naming mechanism. Do not rely only on a colored bar or surrounding visual context.

Using <label>

A <label> can explicitly identify a meter with for and id, or be used implicitly when the meter is nested appropriately. The visible label should describe what is being measured, not merely say “meter.”

Fallback content

Content inside <meter> can provide a textual fallback such as “72 out of 100.” Keep it useful and synchronized with the underlying measurement when it is intended to communicate the same information.

Content model

The content model is phrasing content, but a meter must not contain another meter descendant. This is an authoring rule, not an invitation to build nested gauges.

HTML content categories

<meter> is flow content, phrasing content, labelable content, and palpable content. It is therefore usable in contexts that accept phrasing content and participates in labeling semantics.

Tag omission

Neither the start tag nor the end tag is omissible. Write both tags even when the fallback content is empty.

Intermediate

Global attributes

Global HTML attributes apply as usual. Element-specific semantics come from value, min, max, low, high, and optimum.

Native accessibility semantics

A native <meter> carries the meter semantics. Do not replace it with a generic element plus ARIA merely to reproduce a native gauge when the native element expresses the concept directly.

Do not override the native role

The native meter semantics should not be replaced with an arbitrary ARIA role. The platform mapping is part of what makes the native element useful to assistive technologies.

Descendant semantics

Because the element is exposed as a meter-like gauge, authors should not place important semantic structure inside it and expect that structure to behave like ordinary document content in every accessibility tree.

The labels property

HTMLMeterElement exposes a read-only labels collection for associated label elements. This is useful when inspecting or testing the element’s accessible labeling relationships.

HTMLMeterElement

The DOM interface is HTMLMeterElement. Its value, min, max, low, high, and optimum properties reflect the corresponding content attributes as numeric values.

Attribute/property reflection

Changing a reflected DOM property changes the corresponding content attribute. Conversely, changing the attribute updates the reflected property according to HTML’s reflection rules and numeric parsing behavior.

Numeric normalization

Meter values are numbers, not arbitrary strings. Malformed or out-of-range values are interpreted through the HTML element’s algorithms, so application code should not assume that the raw attribute string equals the effective gauge value.

Updating a meter with JavaScript

For a live measurement, update the meter’s value property from the authoritative application state. Avoid maintaining several independent numeric sources that can drift apart.

Model the measurement first

Before writing markup, define what the quantity means, its real minimum and maximum, and whether lower, middle, or higher values are preferable. The HTML attributes should encode that model rather than invent it.

Units and presentation

The meter does not encode arbitrary units such as MB, °C, or points as separate semantics. Provide the unit in surrounding or fallback text when the user needs it, and ensure the accessible name identifies the measured quantity.

Percentages

A percentage is a presentation of a ratio, not automatically a reason to use <progress>. If the percentage describes a stable measurement within a meaningful range, <meter> may be appropriate; if it describes task completion, use <progress>.

Storage usage example

Storage usage is a classic meter case: used space is a scalar within a known capacity. The maximum is the capacity, while low/high/optimum can express what counts as desirable or concerning.

Score example

A score can be a meter when it represents a scalar within a known meaningful range. A score of 82 out of 100 is a measurement; “82% of the file has uploaded” is task progress and belongs to <progress>.

Temperature example

Temperature can be modeled as a meter when the application has meaningful bounds and an optimum. The optimum may be in the middle, demonstrating why “high value equals good” is not a universal assumption.

Relevance and confidence

Search relevance or confidence can be represented as a gauge when the application has a meaningful bounded scale. Explain the scale clearly rather than implying that an arbitrary number is universally interpretable.

Not an arbitrary number display

Do not use <meter> simply because you want a stylized number with a bar. If there is no meaningful range or measurement concept, a normal text element or another semantic element is more appropriate.

Why arbitrary weight is a poor example

The HTML specification specifically distinguishes a known-range measurement from an arbitrary scalar. A person’s weight, for example, should not be turned into a meter merely because kilograms are numeric unless the application defines a meaningful range and measurement semantics for the gauge.

Native rendering

Browsers may render a native meter with platform-specific visual treatment. The HTML semantics are stable while the exact pixels are not guaranteed.

CSS styling boundary

CSS can style a meter, but the most detailed native subparts and pseudo-elements are browser-specific. Avoid depending on non-standard selectors when the component must behave consistently across engines.

appearance and custom visuals

Replacing the native appearance with a custom visualization transfers more responsibility to the author. Preserve the native semantics and accessible name even when presentation changes.

Direction and RTL

In right-to-left writing, the visual direction of a native meter can differ from left-to-right expectations. Do not encode direction assumptions into application logic; let writing direction and the user agent’s native rendering semantics do their work.

Vertical writing

Writing modes can change the visual orientation of native gauges. Treat orientation as presentation and test the result in the writing modes your product supports.

Color is not the semantic

Do not communicate low, normal, or high status only with color. The semantic thresholds belong in the meter model, while text, labels, and accessible naming should make the meaning understandable without relying on color perception.

Animation considerations

A continuously changing meter can be visually distracting and computationally wasteful. Update at a useful cadence and avoid animation that obscures the actual measurement.

Advanced

Events and observation

A meter itself is not a user-editable form control. Application code generally changes its value in response to other events, such as input, network updates, timers, or state changes.

Relationship to forms

Although <meter> is labelable, it is not a user input control that contributes a successful form value. Do not expect its value to become form-submitted data.

Constraint validation boundary

A meter does not participate in constraint validation like user-editable controls do. If an application needs to validate a measured value, perform that validation in application logic or on the server as appropriate.

Security boundary

A meter is presentation of application state, not an authorization mechanism. Never trust a client-side meter to prove that a user has completed work, paid a balance, passed a threshold, or obtained permission.

Untrusted measurement data

Measurements received from a server or another client can be stale, manipulated, or malformed. Normalize and validate data before presenting it, and keep security decisions on trusted boundaries.

Asynchronous measurements

When measurements arrive asynchronously, associate updates with the correct entity and state. A late response must not overwrite a newer measurement simply because it arrived afterward.

Avoid stale update races

Use request identifiers, abort signals, timestamps, or state-version checks when appropriate. The meter should reflect the application’s current authoritative state, not the last callback that happened to run.

Precision and false accuracy

Do not display more precision than the measurement supports. A meter showing 72.4837% can imply accuracy the underlying measurement does not have.

Choosing thresholds responsibly

low and high should correspond to meaningful product thresholds. They are not merely decoration for green/yellow/red styling.

Choosing optimum responsibly

optimum should represent the preferred value or region for the measured quantity. If no value is inherently preferable, do not invent an optimum merely to trigger a visual treatment.

Accessibility testing

Test the accessible name and exposed meter value with browser accessibility tooling and assistive technology where practical. Verify that the surrounding text explains units and meaning.

DOM testing

Test the effective numeric properties, attribute reflection, labels, threshold relationships, and dynamic updates. Do not make pixel snapshots the only test of a meter implementation.

Cross-browser testing

Native rendering differs across browsers and platforms. Test semantics and behavior across supported engines, then treat visual differences as an expected platform boundary unless your product explicitly requires a custom presentation.

Progressive enhancement

Start with valid native <meter> semantics and meaningful fallback text. Add styling and scripting as enhancements rather than rebuilding the gauge from a generic div by default.

When a custom gauge is justified

A custom visualization may be justified when the product needs a visual form the native meter cannot provide. Keep the semantic model explicit and ensure the custom representation remains accessible and synchronized.

Production architecture

Keep the measured value in one authoritative state model, derive the meter attributes from that state, and keep formatting separate from measurement. This prevents UI strings, CSS widths, and numeric state from drifting apart.

State modeling

For complex gauges, model states such as unavailable, loading, known measurement, stale measurement, and error explicitly. Do not encode every state as a misleading numeric value.

Unknown measurement

If the application does not know a meaningful measurement, do not manufacture a number merely to fill the bar. Use appropriate text or a separate status representation until a real measurement exists.

Error state

A failed measurement is not automatically zero. Distinguish “zero,” “unknown,” and “failed to retrieve” so the UI does not communicate a false quantitative result.

Localization

Localize the human-readable label, units, number formatting, and fallback text. Keep the semantic numeric model independent from localized presentation.

Performance

A meter is cheap, but an application that updates hundreds of meters many times per second is not. Batch state updates and update the DOM at a useful frequency rather than on every internal tick.

Guru exercise

Build a reusable storage-health gauge that reports used capacity, meaningful low/high thresholds, an optimum, localized text, stale-data handling, and accessible labeling. Then test its DOM semantics, dynamic updates, RTL presentation, and security boundary.

Production checklist

Before shipping, verify that the value is a real bounded measurement; min/max describe the actual range; low/high/optimum have meaningful semantics; the meter has an accessible name; fallback text is useful; JavaScript has one authoritative source of truth; security decisions do not trust the meter; and cross-browser styling is treated as a presentation boundary.