In short
Implement a type scale as CSS custom properties following a consistent modular ratio, use relative units (rem) so sizes respect user font preferences, and adjust the scale responsively at a small number of breakpoints rather than hardcoding a fixed size per screen.
Defining the scale as variables
Set up each type-scale step as a CSS custom property rather than hardcoding font sizes throughout your stylesheets:
``css :root { --font-size-xs: 0.75rem; --font-size-sm: 0.875rem; --font-size-base: 1rem; --font-size-lg: 1.25rem; --font-size-xl: 1.5rem; --font-size-2xl: 2rem; --font-size-3xl: 2.5rem; } ``
Every component references these variables rather than a raw pixel or rem value, so a scale-wide adjustment happens in one place instead of requiring a find-and-replace across the codebase.
Choosing a modular ratio
A modular scale multiplies a base size by a consistent ratio at each step — 1.2 (minor third) and 1.25 (major third) are common, producing a scale that feels proportionally consistent rather than arbitrary. Pick a ratio, generate the scale from it, and resist adjusting individual steps by eye afterward, which reintroduces the inconsistency a modular scale is meant to prevent.
Using rem, not px
Define font sizes in rem units, which scale relative to the root element's font size, rather than fixed px values. This respects a user's browser-level font size preference — an accessibility feature some users rely on — which fixed pixel values silently override.
Responsive adjustment at a few breakpoints
Rather than scaling every size continuously with viewport width (which can produce oddly-sized, unpredictable text at in-between widths), adjust the scale at a small number of deliberate breakpoints — perhaps a slightly compressed scale on mobile and the full scale from tablet up. This keeps the type scale predictable and testable at each breakpoint rather than an infinite, hard-to-verify continuum.
Line height as part of the scale
Pair each size with an appropriate line height as part of the same token — larger headline sizes typically need tighter relative line height, while body text needs more generous line height for readability. Defining --line-height-lg alongside --font-size-lg keeps this pairing intentional rather than left to per-component guesswork.
Keeping design and code in sync
The CSS variable names and values should match the type scale steps defined in your design tool's type styles exactly — a mismatch here (a designer using a size that doesn't exist as a token) is one of the most common sources of ad hoc, off-scale text sizes creeping into a shipped product.
Verifying the scale in practice
After implementation, audit a handful of real screens and confirm every visible text size traces back to a scale variable rather than a one-off value — this is a quick way to catch drift early, before off-scale sizes accumulate across the codebase.
Further reading: the W3C Design Tokens Community Group publishes primary guidance behind the practices covered here.
Common questions
Should I use px or rem for a type scale?
rem — it scales relative to the user's browser font size setting, respecting an accessibility preference that fixed pixel values silently override.
What modular ratio should I use for a type scale?
1.2 or 1.25 are common, reliable choices — the specific ratio matters less than applying it consistently to generate every step rather than adjusting individual sizes by eye.
Should the type scale change at different screen sizes?
Often yes, but adjust it at a small number of deliberate breakpoints rather than scaling continuously with viewport width, which can produce unpredictable in-between sizes.
