Type Scale Systems

A type scale is a set of font sizes derived from a single base size and a consistent multiplier — the ratio. Starting from a base of 16 px and multiplying repeatedly by 1.25 gives you 20, 25, 31.25, 39.06, and so on. Each step is mathematically related to the others, which is what makes the resulting text feel harmonious without any manual tuning.

The term comes from music: a major scale has predictable intervals between notes, and a type scale has predictable intervals between sizes. Picking arbitrary pixel values — 14, 17, 22, 28 — breaks those intervals and forces the eye to do extra work interpreting hierarchy. A well-chosen ratio does that work for you.

The six most common ratios each have a name borrowed from music theory: Minor Second (1.067), Major Second (1.125), Minor Third (1.2), Major Third (1.25), Perfect Fourth (1.333), and Augmented Fourth (1.414). Smaller ratios create subtle, compact hierarchies suited to dense UIs. Larger ratios produce dramatic, editorial contrasts suited to landing pages and marketing.

The ratio is the single most important decision in a type scale. It controls how much contrast exists between adjacent steps. A ratio that is too small produces sizes that look nearly identical, making hierarchy invisible. A ratio that is too large produces extreme jumps that leave gaps in the scale — you end up with no usable size for body text, subheadings, and page titles simultaneously.

A good rule of thumb: use a smaller ratio (1.125–1.2) for product UIs with dense information — data tables, admin dashboards, developer tools. Use a larger ratio (1.25–1.333) for content-focused interfaces — blogs, marketing sites, portfolios. The Major Third at 1.25 sits at the intersection: dramatic enough to establish clear hierarchy, compact enough to cover all semantic levels without running into absurdly large display sizes.

A type scale only becomes a system when the sizes are encoded as design tokens — CSS custom properties that are defined once and consumed everywhere. Hard-coding font-size: 24px in a component breaks the connection to the scale; using font-size: var(--font-size-h4) means the component inherits any future scale adjustment automatically.

Token naming should encode semantic role, not raw value. Prefer --font-size-h2 over --font-size-40: the first name survives a ratio change, the second becomes a lie the moment you update the value. If you need both semantic and numeric names, map one to the other rather than defining both independently.

Static tokens give you a consistent scale, but on a 320 px phone a heading at 40 px can overflow its container, and on a 2560 px monitor 16 px body text becomes uncomfortably small. The solution is to replace fixed rem values with clamp() expressions that scale proportionally between a minimum at 320 px and a maximum at 1280 px.

The fluid preferred value can be derived mechanically: given that you want minSize at minVW and maxSize at maxVW, the slope is (maxSize − minSize) / (maxVW − minVW) and the intercept is minSize − slope × minVW. Written as a calc(): intercept + slope × 100vw.

In practice you rarely compute this by hand — a tool like clamp.font-size.app generates the expression for any min/max pair. What matters is understanding the structure so you can adjust the endpoints intentionally when the scale needs to shift for a specific design context.

Notice that body steps use static values or very gentle clamps — their legibility floor is the critical constraint, and aggressive scaling would make body text uncomfortable on mid-size viewports. The fluid range is concentrated in the heading steps where the visual benefit is highest and the risk of over-scaling is lower.

Once tokens are defined, the rule is simple: every font-size declaration in a component must reference a token. Never write a raw size. This creates a single source of truth — updating a token propagates instantly across every component that uses it, without searching the codebase for font-size: 24px.

The semantic token names also serve as documentation. A developer reading font-size: var(--font-size-h4) immediately understands the intent. Reading font-size: 1.5rem requires mental decoding and provides no guarantee the value is on-scale.

A complete type scale system comes down to three decisions made once and enforced everywhere. First, choose a ratio that matches the visual density of your product — 1.25 is a safe default. Second, encode every step as a CSS custom property with a semantic name — --font-size-h2 not --font-size-40px. Third, make the heading steps fluid with clamp() so the scale responds to the viewport without breakpoints.

After that, the rule is mechanical: if a component needs a font-size, it uses a token. No exceptions. The scale pays compound interest — every component that follows the rule makes future refactors cheaper and the overall type hierarchy more coherent.