Building a Type Scale for Your Design System

A type scale is one of the most consequential decisions you will make for a design system. Get it right, and every product that consumes your system inherits a visual hierarchy that works effortlessly across screens, contexts, and component combinations. Get it wrong, and every team building on top of your system will fight against it — adding one-off sizes, overriding tokens, and creating the typographic chaos that design systems are supposed to prevent.

This guide walks through the complete process: understanding why a type scale matters, choosing your mathematical ratio, naming your steps, implementing them in CSS and design tokens, and adapting the scale to different viewport sizes.

Why Every Design System Needs a Type Scale

Before defining what a type scale is, it helps to understand what happens without one. On any sufficiently large product — a SaaS dashboard, an e-commerce platform, a documentation site — individual contributors will reach for font sizes that "feel right" in isolation. A product designer sets a card title to 18px. A different designer working on a modal header picks 20px. A front-end engineer adds a section heading at 22px because the copy felt heavy at 20px. Over six months, the codebase contains fourteen distinct font sizes, none of them aligned to any shared logic.

A type scale replaces that entropy with a constrained set of sizes derived from a single mathematical rule. Every size in the scale relates to every other size through the same ratio. This means:

Visual harmony. Sizes that share a mathematical relationship look related. The jump between body text and a subheading feels intentional rather than arbitrary.

Faster decisions. Designers do not evaluate whether 17px or 18px is more appropriate. They evaluate which step on the scale best represents the hierarchy level they need.

Predictable implementation. Engineers do not hard-code pixel values. They reference named tokens — --font-size-lg, --font-size-xl — and those tokens change in one place when the base size or ratio changes.

System-wide consistency. When a component library, a marketing site, and a mobile app all reference the same scale, text reads consistently across surfaces even when the components themselves differ.

Design systems from Material Design to IBM Carbon to Shopify Polaris all define explicit type scales for exactly these reasons. Building your own system without one forces every downstream team to make decisions that should have been made once, centrally.

Choosing Your Scale Ratio

The ratio is the multiplier you apply at each step of your scale. Starting from a base size, multiplying by the ratio gives you the next larger step; dividing by it gives you the next smaller step.

Several ratios have names drawn from Western music theory, because the same mathematical proportions appear in musical intervals. The most commonly used in interface design are:

For most UI design systems, ratios between 1.200 and 1.333 are the practical sweet spot. Here is why the extremes fail:

Too tight (below 1.125): The difference between adjacent steps is so small that hierarchy becomes ambiguous. A heading and a subheading set two steps apart barely look different. You end up needing more steps to achieve legible hierarchy, which makes the scale unwieldy.

Too dramatic (above 1.414): The jump between steps becomes so large that the scale quickly produces sizes that are either too tiny to read comfortably or too large to fit in practical UI containers. A scale with a 1.618 ratio starting from 16px reaches 42px in just four steps, leaving little room for fine-grained hierarchy.

The 1.250 (Major Third) sweet spot: Starting from a base of 16px, each step is clearly distinct from the previous one. A designer moving from body text to a section heading moves two or three steps and lands at a size that reads unmistakably as a heading without dominating the page. This ratio is close to what IBM Carbon's type scale uses in its dense UI contexts.

When to choose 1.333 (Perfect Fourth): If your product has strong visual hierarchy requirements — a content-heavy editorial product, a dashboard with deeply nested section levels — the Perfect Fourth gives you more breathing room between steps. Material Design 3's type scale effectively approximates this range for its larger display sizes.

Choosing a base size: The starting point is almost always 16px. This is the browser default, the size at which body text reads comfortably across typical viewing distances for both desktop and mobile. The Inter typeface — designed specifically for screen reading — was engineered around this baseline. Changing the base to 15px or 17px is possible but rarely worth the deviation from the established norm.

Once you have chosen your ratio, use a tool like Modular Scale or write a quick script to generate the raw values:

Base: 16px, Ratio: 1.250

Step -2: 16 ÷ 1.250 ÷ 1.250 = 10.24px
Step -1: 16 ÷ 1.250        = 12.80px
Step  0: 16                = 16px     (base)
Step  1: 16 × 1.250        = 20px
Step  2: 16 × 1.250²       = 25px
Step  3: 16 × 1.250³       = 31.25px
Step  4: 16 × 1.250⁴       = 39.06px
Step  5: 16 × 1.250⁵       = 48.83px

You will notice the raw values are rarely round numbers. This is expected and should not be rounded aggressively. Modern CSS handles sub-pixel rendering well, and rounding to the nearest 4px or 8px to align with a spacing grid often destroys the harmonic relationship between steps.

Defining Scale Steps and Naming Conventions

With raw values in hand, the next decision is how many steps to expose and what to name them.

How many steps you need depends on your product's complexity. A simple marketing site might need five: two below the base for captions and small labels, the base for body text, and two above for headings. A complex SaaS product might need eight to ten: caption, helper text, body-sm, body, body-lg, heading-sm, heading-md, heading-lg, display-sm, display.

Naming approaches fall into two camps:

T-shirt sizing (xs, sm, md, lg, xl, 2xl, 3xl) is intuitive and has become the most common convention, popularized by Tailwind CSS. It works well when the scale is stable and unlikely to add steps between existing ones. The weakness: inserting a step between lg and xl requires either renaming everything or creating awkward names like lg-plus.

Numeric naming (100, 200, 300 through 900 or similar) leaves room for future steps. A scale might use 200, 300, 400 (base), 500, 600, 700, 800. Adding a step between 400 and 500 later is feasible. IBM Carbon uses numeric naming for its type scale steps.

Semantic naming (body, caption, heading-1 through heading-4, display) communicates intent rather than size. The advantage is clarity — engineers reading a component know what role a given size plays. The disadvantage is rigidity — a size named heading-1 is hard to repurpose for a display banner without the name becoming misleading.

In practice, the most robust design systems use a combination: a primitive numeric or t-shirt scale at the foundation (the "raw" values), and semantic aliases on top of those primitives for use in components. This is the token layering pattern discussed in detail in Typography Design Tokens: From Figma to CSS.

A practical example — a 9-step scale with semantic aliases:

Implementation in CSS and Design Tokens

With the scale defined, implementation happens in layers. The innermost layer is the raw CSS custom property definition. The outer layers build semantic meaning on top.

Layer 1: Primitive tokens

Define the raw values as CSS custom properties on :root. These are the source of truth and should never be referenced directly in components.

:root {
  --font-size-100: 0.64rem;   /* 10.24px at 16px base */
  --font-size-200: 0.8rem;    /* 12.80px */
  --font-size-300: 1rem;      /* 16px — base */
  --font-size-400: 1.25rem;   /* 20px */
  --font-size-500: 1.5625rem; /* 25px */
  --font-size-600: 1.953rem;  /* 31.25px */
  --font-size-700: 2.441rem;  /* 39.06px */
  --font-size-800: 3.052rem;  /* 48.83px */
  --font-size-900: 3.815rem;  /* 61.04px */
}

Note the use of rem rather than px. Rem units scale with the user's browser default font size, preserving accessibility for users who have set a larger base font size. If a user has set their browser to 20px, your 1.25rem (nominally 20px at 16px base) becomes 25px — maintaining the visual relationship while respecting user preference.

Layer 2: Semantic tokens

Map semantic names to primitives. These are the tokens that components actually use.

:root {
  --font-size-caption-sm: var(--font-size-100);
  --font-size-caption:    var(--font-size-200);
  --font-size-body-sm:    var(--font-size-200);
  --font-size-body:       var(--font-size-300);
  --font-size-body-lg:    var(--font-size-400);
  --font-size-heading-sm: var(--font-size-500);
  --font-size-heading-md: var(--font-size-600);
  --font-size-heading-lg: var(--font-size-700);
  --font-size-display-sm: var(--font-size-800);
  --font-size-display:    var(--font-size-900);
}

Layer 3: Component usage

Components reference only semantic tokens. This means the type scale can evolve without touching component CSS.

.card-title {
  font-size: var(--font-size-heading-sm);
  font-weight: 600;
  line-height: 1.3;
}

.body-text {
  font-size: var(--font-size-body);
  font-weight: 400;
  line-height: 1.6;
}

.caption {
  font-size: var(--font-size-caption);
  font-weight: 400;
  line-height: 1.5;
  color: var(--color-text-secondary);
}

Pairing with line-height: Font size without line-height is incomplete. A practical rule: tighter line-height for large sizes (display text at 1.1 to 1.2), standard line-height for body text (1.5 to 1.6), and slightly looser for small sizes (1.4 to 1.5 for captions). Build line-height tokens alongside your font-size tokens and apply them together.

:root {
  --line-height-tight:   1.15;
  --line-height-snug:    1.3;
  --line-height-normal:  1.5;
  --line-height-relaxed: 1.65;
}

Design token formats beyond CSS: If your system needs to distribute tokens to iOS, Android, or design tools, consider the W3C Design Token format or tools like Style Dictionary. Style Dictionary can transform a single JSON or YAML source of truth into CSS custom properties, JavaScript constants, Swift values, and XML for Android from one definition.

Responsive Type Scale Adjustments

A type scale defined for desktop often needs adjustment on smaller screens. The challenge is that a 61px display heading that looks commanding on a 1440px desktop becomes overwhelming on a 375px phone — it may not even fit on one line.

Two strategies for responsive scaling:

Strategy 1: Breakpoint-based scale switching

Define a second, smaller set of primitive values for mobile and switch the semantic tokens at a breakpoint.

:root {
  /* Desktop scale — 1.250 ratio */
  --font-size-700: 2.441rem;  /* 39.06px */
  --font-size-800: 3.052rem;  /* 48.83px */
  --font-size-900: 3.815rem;  /* 61.04px */
}

@media (max-width: 768px) {
  :root {
    /* Mobile scale — steps pulled back by 1-2 */
    --font-size-700: 1.953rem;  /* 31.25px — was 600 on desktop */
    --font-size-800: 2.441rem;  /* 39.06px — was 700 on desktop */
    --font-size-900: 3.052rem;  /* 48.83px — was 800 on desktop */
  }
}

Because semantic tokens map to primitive tokens, and components use only semantic tokens, this change flows through the entire system automatically. Every display-sm size on the site changes without touching a single component.

Strategy 2: Fluid type scaling with clamp()

CSS clamp() enables font sizes that scale smoothly between a minimum and maximum value based on viewport width, with no breakpoints needed.

:root {
  --font-size-display: clamp(2.5rem, 5vw + 1rem, 3.815rem);
  --font-size-display-sm: clamp(2rem, 4vw + 0.75rem, 3.052rem);
  --font-size-heading-lg: clamp(1.75rem, 3vw + 0.5rem, 2.441rem);
  --font-size-heading-md: clamp(1.375rem, 2vw + 0.5rem, 1.953rem);
  --font-size-heading-sm: clamp(1.125rem, 1.5vw + 0.5rem, 1.5625rem);
  --font-size-body:       clamp(1rem, 1vw + 0.75rem, 1.125rem);
}

The clamp(min, preferred, max) syntax sets a floor and ceiling with a viewport-proportional preferred value in between. The fluid typography calculator can generate these values automatically.

Which strategy to choose: Breakpoint-based switching is simpler to reason about and test — you know exactly what size renders at each viewport. Fluid scaling produces smoother visual transitions but can be harder to debug and may require more testing across the viewport range to ensure nothing breaks mid-scale. Many production systems use fluid scaling only for display and heading sizes, leaving body and caption sizes fixed to preserve reading comfort.

The body text exception: Body text (16px) rarely needs to scale with viewport. The reading experience at 16px is already calibrated for comfortable reading distances at both desktop and mobile. Scaling body text smaller on mobile can actually hurt readability. Reserve responsive scaling for the upper and lower extremes of your scale.

A well-built type scale pays dividends every time a designer opens a component in Figma or an engineer writes a new component in code. It is not a one-time configuration but a living specification — revisit it as your product's needs evolve, and treat changes to the base or ratio as system-level decisions that deserve thorough testing across every component in your library.

The next step after defining a scale is codifying it as design tokens and establishing a workflow that keeps Figma and code in sync. That process is covered in Typography Design Tokens: From Figma to CSS.