CSS Typography Scale: fluid type with clamp() and modular scale

Why Your Current Typography Scale Is Probably Wrong

Most devs copy a type scale from somewhere, drop it into their CSS, and call it done. Then they spend the next six months writing font-size: 14px overrides scattered across a dozen media queries. Sound familiar?

The problem isn't the scale itself — it's that the scale is static. You define h1 { font-size: 48px } at 1440px and it looks great. At 375px on a phone, that same 48px heading is taking up half the viewport and wrecking your layout. So you add a breakpoint. Then another. Then a clamp() someone pasted from Stack Overflow that doesn't quite match your ratios.

There's a cleaner way. Build your scale with modular ratios from the start, express every step with clamp(), and you get fluid type that scales *continuously* — not in discrete jumps. No breakpoints for font sizes. Ever. Honestly, once you've shipped a system this way, going back to pixel overrides feels like using tables for layout.

This article walks through the exact math, the CSS custom properties pattern, and the JSX token setup you'd use in a real design system.

Understanding Modular Scale — The Math Behind the Magic

A modular scale is just a geometric sequence. You pick a base size (say 16px) and a ratio, then multiply repeatedly. The ratio is where the personality comes from. A 1.25 ratio (Major Third) gives you a gentle progression. A 1.618 ratio (Golden Ratio) gives you dramatic jumps. A 1.333 ratio (Perfect Fourth) is the sweet spot most design systems land on in 2024–2026.

Here's the full sequence with a base of 16px and a Perfect Fourth ratio of 1.333:

Step  |  Calculation          |  Result
------+-----------------------+--------
-2    |  16 / 1.333²          |  ~9px
-1    |  16 / 1.333           |  ~12px
 0    |  16                   |  16px   (base)
+1    |  16 × 1.333           |  ~21px
+2    |  16 × 1.333²          |  ~28px
+3    |  16 × 1.333³          |  ~38px
+4    |  16 × 1.333⁴          |  ~50px
+5    |  16 × 1.333⁵          |  ~67px

Worth noting: you don't have to round these values. CSS handles sub-pixel rendering fine, and keeping the exact floats means your scale stays mathematically consistent across the whole system. Rounding to nice numbers breaks the relationship between steps.

In practice, most interfaces only need about 6–8 stops on the scale. Anything beyond step +4 is display type — hero headings, landing page statements. Anything below step -1 is legal text and captions. Map your semantic tokens (body, caption, h1–h4) to scale steps, not to raw pixel values.

Building Fluid Type with clamp()

clamp(min, preferred, max) is the key. It takes a minimum value, a preferred value (usually viewport-relative), and a maximum value. The font size grows with the viewport but never goes below the min or above the max. No media queries needed.

The preferred value is the tricky part. You want it to interpolate linearly between your min and max across a viewport range. Let's say your viewport range is 320px to 1280px. For a step that should be 16px at 320px and 21px at 1280px, the calculation is:

/* Formula:
   preferred = min + (max - min) * (100vw - minVW) / (maxVW - minVW)
   Simplified into a linear equation: */

--text-base: clamp(
  1rem,
  0.9286rem + 0.3571vi,
  1.3125rem
);

That vi unit (1% of the viewport's inline size) is what makes it smooth. You can derive all those numbers by hand, but you'd normally generate them from a small utility function — shown in the next section. The pattern holds for every step in your scale. Each custom property on :root becomes a single clamp() expression, and your component styles just reference the token name.

Quick aside: vi is equivalent to vw in horizontal writing modes, but it's the correct unit to use for inline size. Browser support has been solid since 2023, so you're fine to ship it today.

The CSS Custom Properties Setup — Full Code Example

Here's a real, working type scale with 7 steps built on a 1.333 ratio, a 16px base, and a viewport range from 320px to 1280px. Drop this in your global CSS or design tokens file.

:root {
  /* ── Fluid Type Scale (Perfect Fourth, 1.333) ── */
  /* base: 16px @ 320px → 21px @ 1280px */

  --text-xs:   clamp(0.6944rem, 0.6608rem + 0.1680vi, 0.7901rem);  /* ~11px */
  --text-sm:   clamp(0.8333rem, 0.7934rem + 0.1996vi, 0.9375rem);  /* ~13–15px */
  --text-base: clamp(1rem,      0.9286rem + 0.3571vi, 1.3125rem);  /* ~16–21px */
  --text-md:   clamp(1.333rem,  1.2381rem + 0.4762vi, 1.75rem);    /* ~21–28px */
  --text-lg:   clamp(1.777rem,  1.6509rem + 0.6306vi, 2.3333rem);  /* ~28–37px */
  --text-xl:   clamp(2.369rem,  2.2000rem + 0.8452vi, 3.1111rem);  /* ~38–50px */
  --text-2xl:  clamp(3.157rem,  2.9335rem + 1.1176vi, 4.1481rem);  /* ~50–66px */

  /* Semantic mappings */
  --font-caption:  var(--text-xs);
  --font-body-sm:  var(--text-sm);
  --font-body:     var(--text-base);
  --font-lead:     var(--text-md);
  --font-h4:       var(--text-md);
  --font-h3:       var(--text-lg);
  --font-h2:       var(--text-xl);
  --font-h1:       var(--text-2xl);
}

/* Apply to HTML elements */
body         { font-size: var(--font-body); }
caption, figcaption { font-size: var(--font-caption); }

h1 { font-size: var(--font-h1); }
h2 { font-size: var(--font-h2); }
h3 { font-size: var(--font-h3); }
h4 { font-size: var(--font-h4); }

The two-layer system matters. Scale steps (--text-*) are the raw math. Semantic tokens (--font-*) are what your components actually consume. When you need to rethink the hierarchy, you change one mapping, not twenty component files.

You can also expose these in a JS/TS tokens object for Tailwind, Styled Components, or whatever you're using — just reference the CSS variable string directly and let the browser do the resolution.

Using the Scale in JSX and Tailwind

If you're building on a component library — or building one, like the components at Empire UI — you want these tokens accessible in JSX. Here's a minimal pattern using a tokens object and inline styles:

// tokens/typography.ts
export const font = {
  caption:  'var(--font-caption)',
  bodySm:   'var(--font-body-sm)',
  body:     'var(--font-body)',
  lead:     'var(--font-lead)',
  h4:       'var(--font-h4)',
  h3:       'var(--font-h3)',
  h2:       'var(--font-h2)',
  h1:       'var(--font-h1)',
} as const;

// components/Heading.tsx
import { font } from '@/tokens/typography';

type Level = 1 | 2 | 3 | 4;

interface HeadingProps {
  level?: Level;
  children: React.ReactNode;
  className?: string;
}

export function Heading({ level = 2, children, className }: HeadingProps) {
  const Tag = `h${level}` as keyof JSX.IntrinsicElements;
  const sizes: Record<Level, string> = {
    1: font.h1,
    2: font.h2,
    3: font.h3,
    4: font.h4,
  };

  return (
    <Tag
      className={className}
      style={{ fontSize: sizes[level] }}
    >
      {children}
    </Tag>
  );
}

That said, if you're using Tailwind v4, you can register your custom properties directly in your CSS config with @theme and access them as utility classes. Check the Tailwind v4 docs — the --font-* pattern maps cleanly to text-[var(--font-h1)] shorthand or to custom utility generation.

One more thing — line height and letter spacing should scale too, but don't try to fluid-interpolate them with clamp. Set them relative to font size with em units instead. A heading at font-size: var(--font-h1) with line-height: 1.1 and letter-spacing: -0.02em will look right at any size. Those ratios stay constant because they're proportional, not absolute.

Pairing the Scale With Design Styles

Typography doesn't exist in a vacuum. The scale you pick should reinforce the visual style of your interface. Glassmorphic UIs tend to favour a 1.25 or 1.333 ratio with light font weights — the type recedes slightly, letting the glass layers be the hero. If you're building glassmorphism components, a tighter scale keeps headings from competing with the background blur.

Neobrutalism is the opposite. You want the dramatic jumps of a 1.5 or even 1.618 ratio. Big, heavy display text on flat colored cards. The scale's extremes are the whole point. The gradient generator is useful here too — bold gradients on hero type are a neobrutalism staple, and having the right type scale makes them land.

Look, the ratio choice is a design decision, not a technical one. There's no objectively correct answer. What matters is picking one, committing to it system-wide, and not making one-off exceptions. The moment you add font-size: 22px somewhere because it 'looked better,' you've broken the system. Just adjust the ratio instead.

Neumorphic and claymorphic styles typically live somewhere in the middle — 1.25 to 1.333 — because the depth effects of those styles demand readable, moderate type that doesn't overwhelm the surface treatment.

Testing and Debugging Your Fluid Scale

The easiest debug tool is your browser's device toolbar. Drag the viewport width slowly from 320px to 1440px while inspecting a heading. You should see the font size change continuously — no jumps. If you see jumps, you've got a media query overriding your clamp, or you've accidentally hardcoded a pixel value somewhere.

Chrome DevTools in 2025+ shows the computed clamp() result in the Styles panel when you hover the value. Use it. You can also log computed values in JS: getComputedStyle(el).fontSize gives you the resolved value at the current viewport width.

Worth noting: test at 320px specifically. That's still a real device width (older iPhones, some Android budget phones), and it's the minimum in your clamp formula. If text is clipping or overflowing at 320px, your minimum size is probably too large for the container, not the formula itself. Add overflow-wrap: break-word and a max-width constraint to the container before touching the scale.

Accessibility check: WCAG 2.1 requires body text at a minimum of roughly 16px equivalent. Your --text-base minimum should never go below 1rem (16px). Caption text is the exception — but even there, 11px at minimum is pushing it for anything that isn't supplementary.

FAQ

Read next