Building a Typography Scale System

Building a Typography Scale System

A typography scale is a set of font sizes with a fixed mathematical relationship. It is the difference between a design where every heading size was eyeballed and one where the sizes feel related - because they are. This guide shows how to pick a ratio, build the scale, make it fluid across screen sizes, and ship it as CSS that a whole team can use.

The Short Answer

• Start from the body size (usually 16px) and multiply by a ratio (1.25 "major third" is the most common UI choice) to get each step up.
• Define 5-7 heading levels plus body, small, and caption sizes - and actually use them instead of inventing new sizes.
• Pair every size with a line-height: large text gets tight leading (1.1-1.25), body text gets generous leading (1.5-1.7).
• Keep line length between 45 and 75 characters for comfortable reading.
• Make the scale fluid with CSS clamp() so type grows smoothly from mobile to desktop instead of jumping at breakpoints.

1. Why a Scale Instead of Eyeballed Sizes

When every size is chosen independently, a design accumulates a dozen near-identical values - 13px here, 14px there, 15px somewhere else - and the visual rhythm disappears. A scale constrains the choices: each size is the base multiplied by the ratio, repeated. The constraint is the point. It forces hierarchy: if two elements need different emphasis, they move a full step apart instead of 1px.

The classic formulation comes from print: Robert Bringhurst's The Elements of Typographic Style describes a modular scale as "a sequence of numbers that relate to one another in a meaningful way." For screens, the most useful ratios are:

A ratio around 1.2-1.25 suits most interfaces. Higher ratios produce display type that dominates; lower ratios produce UI type that whispers.

2. Building the Scale: The Math

Pick a base (the body size) and a ratio. Each step up multiplies by the ratio; each step down divides by it.

Base 16px, ratio 1.25:

Round to sensible values for the final tokens (39px, 49px) - the exact decimals do not matter, the relationship does.

You do not need six heading levels. Most products need: display, h1, h2, h3, body, small, caption. Map HTML heading elements to scale steps in one place so h1 through h3 always mean the same thing.

3. Line-Height, Measure, and Spacing

Size is only one third of type. The other two:

Line-height. Big text needs less leading; small text needs more. Rules of thumb:

• Display / h1: 1.05-1.2
• h2 / h3: 1.2-1.35
• Body: 1.5-1.7
• Small / caption: 1.4-1.5 (short lines need less)

Use unitless values (line-height: 1.5) so the ratio scales with the font size rather than a fixed pixel value.

Measure (line length). Aim for 45-75 characters per line for body text; 60-66 is the classic sweet spot. Narrower than 45 forces too many line breaks; wider than 75 makes the eye work to find the next line. In CSS: max-width: 65ch on article bodies.

Space between type. Vertical rhythm comes from consistent spacing between text blocks, not from the line-height alone. A common pattern: paragraph spacing of 1em-1.5em, and heading margins that scale with the heading size.

4. Fluid Type with clamp()

Fixed pixel sizes break on small screens (headings overflow) and waste space on large ones. clamp() lets a size grow smoothly between a minimum and maximum based on viewport width:

/* H1: 32px on mobile, scaling up to 56px on wide screens */
h1 {
  font-size: clamp(2rem, 1.25rem + 3.75vw, 3.5rem);
}

The middle term is the fluid part. The formula most people use:

• minimum: the mobile size
• maximum: the desktop size
• preferred: min + (max - min) * ((100vw - minViewport) / (maxViewport - minViewport))

There are well-known calculators for this (Utopia's fluid type scale calculator is a popular free one), but the principle is simple: define the two endpoints, interpolate between them. Never let body text go fluid below 16px - small fluid body text becomes unreadable on phones.

5. Shipping It: Type Tokens

Encode the scale as design tokens so every component uses the same sizes:

:root {
  --font-body: 1rem;            /* 16px */
  --font-small: 0.8125rem;     /* 13px */
  --font-caption: 0.75rem;     /* 12px */

  --font-h3: clamp(1.25rem, 1.1rem + 0.75vw, 1.5625rem);
  --font-h2: clamp(1.5625rem, 1.3rem + 1.3vw, 1.9531rem);
  --font-h1: clamp(1.9531rem, 1.5rem + 2.2vw, 2.4414rem);
  --font-display: clamp(2.4414rem, 1.8rem + 3.2vw, 3.0518rem);

  --leading-tight: 1.15;
  --leading-snug: 1.3;
  --leading-normal: 1.6;
}

Then semantic classes or component styles reference the tokens. The rule that keeps the system alive: no raw font-size declarations in components. If a new size is genuinely needed, it goes into the scale first.

6. Font Pairing Basics

A scale controls size; pairing controls voice. Two practical approaches:

• One family, many weights. The safest choice for UI: a single variable font used at different weights and sizes. Zero pairing risk.
• Two families with contrast. A distinctive display face for headings plus a neutral workhorse for body. The contrast should be clear - pairing two similar serifs looks like a mistake; pairing a geometric sans heading with a humanist sans body looks intentional.

Test pairings in context, not in a type tester: set a real headline, a real paragraph, and a real button, then decide. Our guide to choosing fonts for web design covers selection and licensing in depth, and the variable fonts guide explains how one font file can cover the whole weight range.

7. Worked Example: A Scale for a SaaS Marketing Site

Theory is cheap; here is the full decision process for a fictional-but-typical project - a SaaS marketing site with a blog.

Requirements. Marketing pages need dramatic display type; the blog needs comfortable long-form reading; the app UI needs compact, quiet type. One scale must serve all three, so we pick a ratio with range: 1.25.

Base sizes. Body text: 16px for UI, 18px for blog article text (long-form reads better slightly larger). We define the scale once in relative units so both contexts work:

Pairing with leading. Display and h1 get --leading-tight: 1.1; h2/h3 get 1.25; body gets 1.6 (blog body 1.7); small/caption get 1.45.

Verification pass. We set a real hero headline, a real blog paragraph, and a real settings form, then check: does the h1 feel clearly bigger than h2 (yes - a full ratio step)? Is blog body comfortable at 65ch (yes)? Do form labels at 0.875rem stay legible (yes, with 1.45 leading)? One adjustment: marketing wanted a bigger display, so we added a --font-display-xl one step above display rather than breaking the scale with an arbitrary value.

What we did not do. We did not add sizes for special cases ("this card title needs to be slightly bigger"). When a designer asked, the answer was to use the next step up or reconsider the hierarchy. After three months, the scale had eight tokens and zero one-offs - which is the entire point.

8. Common Mistakes

Frequently Asked Questions

What is the best modular scale ratio for web design? 1.25 (major third) is the most versatile default for interfaces. Use 1.2 for calmer products, 1.333+ for editorial or marketing-heavy sites.

Should body text be 16px or larger? 16px is the minimum for comfortable body reading on the web. Many content sites use 17-18px for article text. Never go below 16px for primary reading content.

How many sizes should my scale have? Seven is plenty: display, h1-h3, body, small, caption. More than that usually means the hierarchy is unclear, not that the scale is rich.

Is fluid type safe for accessibility? Yes, with care. Keep a sensible minimum (never below 1rem for body), respect user zoom, and test at 200% browser zoom. Fluid type that shrinks below readable sizes is a failure.

Can I use a type scale with any font? Yes. The scale is about size relationships, which are font-independent. But always spot-check: some fonts run large or small relative to their nominal size, so verify headings against body in the actual typeface.

Continue Reading

• Choosing Fonts for Web Design - selection, pairing, and performance
• The Complete Guide to Variable Fonts - one file for every weight
• Building a Design System from Scratch - where type tokens live