Building a Scale

A type scale is a constrained set of size values — perhaps six to eight steps — that covers every text element in a system. The sizes are not chosen arbitrarily. They follow a ratio, which means the relationships between them are consistent and the visual system has internal coherence. Without a scale, every sizing decision is made independently, and the result is a system without rhythm.

What a scale is and why it works

A modular scale takes a base size — often the body text size — and multiplies it by a ratio to generate larger values, or divides it to generate smaller ones. Common ratios include the Major Third (1.25), the Perfect Fourth (1.333), and the Major Second (1.125). The ratio determines how dramatic the size jumps feel. A 1.5 ratio creates strong contrast between levels. A 1.125 ratio creates subtle gradations suited to dense interfaces.

The benefit of a ratio-based scale is that the size relationships are harmonious. A heading that is 1.333³ times the body size has a mathematical relationship to every other element on the page. The eye perceives this coherence even without consciously recognising the mathematics.

How many steps

Most typographic systems need fewer size steps than designers tend to create. A well-designed interface can work with five to seven sizes: one or two for display headings, one for section headings, one for body text, one for secondary text, and one for captions and labels. Beyond seven, sizes begin to look arbitrary because the steps become too small to read as distinct levels.

The temptation is to add size steps as problems arise — a slightly larger label here, a slightly smaller caption there. Resist this. Adding unlicenced sizes breaks the scale and reintroduces arbitrariness. Work within the defined steps, and if a step is genuinely missing, add it to the scale formally. The scale is constraints as infrastructure: it doesn’t restrict decisions — it makes every sizing decision faster because the vocabulary is already defined.

Applying the scale

The scale defines what sizes exist. A separate decision assigns those sizes to roles: which step is body text, which is H1, which is a label. This assignment should be documented and consistent across the entire interface. A label should be the same size whether it appears on a form, a card, or a navigation item.

Scale and accessibility

WCAG does not set a minimum font size — but practice and research establish useful floors. Body text below 14px at normal weight becomes difficult to read for users with low vision on standard-density screens. The WCAG 1.4.4 success criterion requires that text can be resized to 200% without loss of content; this means type set in pixels that breaks layout at larger sizes fails regardless of its starting size.

More directly relevant is WCAG 1.4.12 (Text Spacing): content must not clip, overlap, or be lost when line height is increased to 1.5× the font size, letter spacing to 0.12em, and word spacing to 0.16em. A type scale built with tight, fixed values rather than relative units (em, rem, lh) is likely to fail these overrides. Design your scale in relative units. See accessible type for the full set of typography accessibility requirements.

See Building a Typographic Hierarchy for how to assign scale steps to reading levels. See Choosing a Typeface for how scale constrains typeface selection.

When to break this

A scale exists to prevent arbitrary sizing decisions. Breaking it reintroduces arbitrariness — unless the exception is handled as rigorously as the scale itself.

When you might break it:

• Display and brand moments — a homepage headline at an unconventional size (very large, or deliberately small for restraint) communicates something the defined scale steps cannot. If the scale’s largest step is 48px, a 96px brand headline is a scale exception with a clear purpose.
• Data labels and constraints — in charts and data visualisations, labels must fit within defined spaces — inside a bar, inside a pie segment, next to a data point. The data’s geometry dictates the size, not the scale. Forcing scale-compliant sizes into cramped data contexts produces unreadable labels.
• Fixed-size component contexts — badge counts, avatar fallback initials, table cell content in dense views. These contexts have physical constraints that the reading scale doesn’t account for.

If you do:

• Define the exception as a named token, not a naked value. text-display-hero, text-data-label, text-badge are scale extensions — documented, purposeful, reusable. font-size: 11px without a name is an unlicensed exception.
• Use rem even for off-scale values so user font-size overrides still apply. A data label at 0.6875rem (11px) responds to user preferences; a label at 11px doesn’t.
• Audit exceptions periodically. Off-scale values that accumulate without review become the new arbitrary system the scale was meant to prevent.