Type Systems for the Modern Web: How to Build a Scale That Survives Redesigns

The Scale That Does Not Break

Most type systems on the web are built for the design comp, not for the site. The designer sets up a scale in Figma with five or six sizes that work perfectly for the three pages in the prototype. Then real content arrives: a project description that is four paragraphs instead of two, a heading that wraps to three lines instead of one, a journal article with nested subheadings. The scale that looked perfect in the comp collapses.

The problem is not bad design. The problem is building a type scale that is too rigid to accommodate the variance in real content. A durable type system needs enough hierarchy to handle complex pages, enough flexibility to adapt to different content lengths, and enough constraint to prevent ad hoc styling decisions that erode consistency.

This is a continuation of the themes we explored in our earlier type systems article, updated for 2026 with specific attention to fluid scaling, CSS container queries, and the practical limits of systematic typography.

Defining the Scale

A type scale is a set of predetermined font sizes, line heights, and spacing values. Everything on the site uses one of these predefined steps. No arbitrary sizes.

For most studio and brand sites, eight steps are sufficient:

• Display: The largest text on the site. Used sparingly for hero headings and major section titles.
• H1: Page titles. One per page.
• H2: Major section headings within a page.
• H3: Subsection headings.
• H4: Minor headings, card titles.
• Body Large: Introductory text, lead paragraphs.
• Body: Default paragraph text.
• Small/Caption: Labels, metadata, timestamps.

Eight steps provide enough granularity for complex editorial content without so many options that the system becomes a free-for-all. If you need more than eight type sizes on a single page, the information architecture needs work, not the type scale.

The Ratio

The mathematical relationship between adjacent sizes gives the scale its visual rhythm. Common ratios:

• 1.125 (Major Second): Subtle hierarchy. Works for text-heavy editorial sites.
• 1.200 (Minor Third): Moderate hierarchy. The sweet spot for most brand sites.
• 1.250 (Major Third): Noticeable hierarchy. Good for sites with strong visual emphasis.
• 1.333 (Perfect Fourth): Bold hierarchy. Works for sites with large headings and minimal body content.

For a body size of 18px with a 1.200 ratio:

• Body: 18px
• Body Large: 21.6px (round to 22px)
• H4: 25.9px (round to 26px)
• H3: 31.1px (round to 31px)
• H2: 37.3px (round to 37px)
• H1: 44.8px (round to 45px)
• Display: 53.7px (round to 54px)
• Small: 15px (18 / 1.200)

These values work well at desktop widths. At mobile widths, the larger sizes need to shrink. That is where fluid scaling comes in.

Fluid Typography

Fluid typography uses clamp() to scale font sizes smoothly between a minimum and maximum based on the viewport width. Instead of jumping between fixed sizes at breakpoints, the type scales continuously.

```

h1 {

font-size: clamp(2rem, 1.5rem + 2.5vw, 3.5rem);

}

```

This sets the H1 to a minimum of 2rem, a maximum of 3.5rem, and a smooth interpolation between them based on viewport width.

The advantage is eliminating the jarring size jumps at breakpoints. The text gets proportionally larger on wider screens and proportionally smaller on narrow screens, maintaining visual balance at every width.

The challenge is calculating the clamp values so that the scale relationships are preserved at both extremes. If the body text is fixed at 18px but the H1 shrinks to 32px on mobile, the ratio between them changes from 2.5x to 1.78x. This might be intentional (you want less hierarchy on small screens), but it should be deliberate, not accidental.

Line Height and Spacing

Font size is half the story. Line height and spacing complete the vertical rhythm.

Line height rules:

• Headings: 1.1 to 1.2. Tighter leading for large text prevents excessive vertical space.
• Body text: 1.5 to 1.6. More generous leading for comfortable reading.
• Small text: 1.4 to 1.5. Slightly tighter than body but still legible.

Spacing rules:

• Space after headings: roughly 0.5 to 0.75 of the heading's line height. Close enough to associate the heading with the content that follows.
• Space between paragraphs: roughly 1 to 1.5 of the body line height. Enough to separate thoughts without fragmenting the page.

These values should be tokenized alongside font sizes so they scale together. When the heading size decreases on mobile, the space after it should decrease proportionally.

CSS Custom Properties as Tokens

The type system should be expressed as CSS custom properties that can be referenced anywhere:

```

:root {

--font-size-display: clamp(2.75rem, 2rem + 3vw, 3.375rem);

--font-size-h1: clamp(2rem, 1.5rem + 2.5vw, 2.8rem);

--font-size-h2: clamp(1.5rem, 1.2rem + 1.5vw, 2.3rem);

--font-size-h3: clamp(1.25rem, 1.1rem + 0.75vw, 1.9rem);

--font-size-body-lg: clamp(1.1rem, 1rem + 0.25vw, 1.35rem);

--font-size-body: clamp(1rem, 0.95rem + 0.15vw, 1.125rem);

--font-size-sm: clamp(0.8rem, 0.75rem + 0.1vw, 0.875rem);

}

```

These tokens become the vocabulary of the type system. Components reference tokens, not arbitrary values. If the scale needs to change, you update the tokens and every component adapts.

This approach also enables design system governance because every type decision references a known set of values. Deviations are visible and reviewable.

When the System Needs to Flex

A type scale works until content breaks it. Common breaking points:

Very long headings. A project title that wraps to four lines in the H1 size. The solution is not to make H1 smaller; it is to use a smaller heading level or to edit the title.

Nested content. A journal article with H2, H3, and H4 subheadings plus a blockquote with its own heading. If the scale only has three heading sizes, the visual hierarchy runs out. The eight-step scale described above handles this well; a five-step scale does not.

Mixed content types. A page that combines a data table, a pull quote, a code block, and regular prose. Each content type has its own typographic needs. The type system should accommodate these with purpose-built styles (table text, code text, quote text) that are still derived from the base scale values.

Testing the Scale

Before committing to a type scale, test it with real content:

1. Render a full-length journal article with all heading levels
2. Render a project page with short and long descriptions
3. Render a listing page with 20+ items
4. Test at mobile, tablet, and desktop widths
5. Test with the longest realistic heading text
6. Test with the shortest realistic heading text

If any of these scenarios produces awkward spacing, hierarchy confusion, or size collisions, adjust the scale before shipping.

FAQ

Should I use px, rem, or em for type sizes?

Use rem for the base scale. Rem units respect the user's browser font size preference, which is an accessibility requirement. Use em only for sizes that should scale relative to their parent (like icon sizes inside buttons).

How many font families should a brand site use?

One or two. A heading family and a body family is the most common pattern. Three families is sometimes justified (adding a monospace for code or technical content). More than three is almost never necessary and increases font loading cost.

Should I use CSS container queries for type scaling?

Container queries are useful when a component appears at different sizes in different contexts (a card in a sidebar vs a card in a main grid). For page-level type scaling, viewport-based clamp() is simpler and more predictable.

The Lasting Principle

A type scale survives redesigns because it is abstract enough to adapt. The specific sizes change, the ratio changes, the typefaces change, but the structural approach remains. Eight steps. Consistent ratios. Fluid scaling. Tokenized values. Tested with real content. That is the system that lasts.