CSS Typography Best Practices Build a system that holds up.

Build the system before polishing the syntax

Good CSS cannot decide what deserves emphasis. Start by naming the text roles in the interface: display, section heading, body, label, caption, and control text. Most products need fewer distinct styles than their design files suggest.

Define those roles as tokens, then let each component use the role it needs. This keeps a one-off card heading from quietly becoming a sixth heading level and makes the implementation easier to tune as a system.

:root {
  /* Start with roles, not a giant generated scale. */
  --font-body: "Body Sans", system-ui, sans-serif;
  --font-display: "Display Serif", Georgia, serif;

  --text-label: 0.875rem;
  --text-body: 1rem;
  --text-lead: 1.25rem;
  --text-section: clamp(1.75rem, 1.35rem + 1.4vw, 2.75rem);
  --text-display: clamp(2.5rem, 1.5rem + 4vw, 5.5rem);

  --leading-tight: 1.08;
  --leading-body: 1.6;
  --measure: 68ch;
}

body {
  font-family: var(--font-body);
  font-size: var(--text-body);
  line-height: var(--leading-body);
}

h1, h2, h3 {
  font-family: var(--font-display);
  line-height: var(--leading-tight);
  text-wrap: balance;
}

.prose {
  max-inline-size: var(--measure);
}

Use a bounded fluid scale—not fluid type everywhere

CSS clamp() combines a minimum, a preferred fluid value, and a maximum. It is useful when a display heading should grow with the available space without jumping through several breakpoints.

It is not a reason to make every label and paragraph drift with the viewport. Stable body and interface text often creates a calmer, more predictable system. Use fluid sizing where the composition benefits from it, then test the values between the endpoints—not only at desktop and mobile.

Set the reading conditions around the font

A typeface can look perfectly readable in a specimen and struggle in a real interface. Line length, line height, size, weight, spacing, contrast, and the language all change the result. That is why a single universal number rarely solves the page.

Make font loading a deliberate tradeoff

A web font affects more than style. It can delay visible text, swap after the page appears, and move the layout when its metrics differ from the fallback. The right loading strategy depends on how important that face is and what happens when it arrives late.

@font-face {
  font-family: "Project Sans";
  src: url("/fonts/project-sans-variable.woff2") format("woff2");
  font-style: normal;
  font-weight: 300 800;
  font-display: swap;
}

:root {
  --font-body: "Project Sans", system-ui, sans-serif;
}

If the fallback causes a visible shift, measure it against the chosen web font before adding size-adjust, ascent-override, descent-override, or line-gap-override. Copied metric values can make the match worse.

If you use Next.js, let the framework own the routine work

The current next/font loaders self-host font files, remove browser requests to Google for Google Fonts, and optimize loading. That is usually a more reliable starting point than hand-building the same pipeline.

import { Inter } from 'next/font/google'

const inter = Inter({
  subsets: ['latin'],
  variable: '--font-body',
})

export default function RootLayout({ children }) {
  return (
    <html lang="en" className={inter.variable}>
      <body>{children}</body>
    </html>
  )
}

Use variable fonts when the range earns its place

A variable font stores a range of variations—commonly weight, width, slant, or optical size—inside one font resource. It can replace several static files and make the type more adaptable, but it is not automatically smaller or better.

1. 1
   Inspect the available axes

   Use registered properties such as font-weight and font-stretch when they express the axis. Reach for font-variation-settings only when you need a lower-level or custom axis.
2. 2
   Use the range the interface needs

   If the product uses only regular and bold, compare the real variable file with two static files. Do not ship unused range for the idea of flexibility.
3. 3
   Test extremes and fallbacks

   Check the lightest, heaviest, narrowest, and widest states you expose, plus the browser fallback when an axis or font is unavailable.

Let components adapt to their space

Viewport-based type works for page-level composition. Reusable cards, panels, and modules often care more about the width of their own container. Container query units can help a component respond to the space it actually receives.

.card-grid {
  container-type: inline-size;
}

.card-title {
  font-size: clamp(1.25rem, 1rem + 2cqi, 2rem);
}

@container (width < 22rem) {
  .card-meta {
    font-size: 0.875rem;
  }
}

Test the failures accessibility settings can reveal

Accessibility is not a style preset. It is evidence about whether people can perceive, resize, space, and operate the content. The useful checks are specific enough to reproduce.

/* Apply temporarily to test WCAG 1.4.12. */
* {
  line-height: 1.5 !important;
  letter-spacing: 0.12em !important;
  word-spacing: 0.16em !important;
}

p {
  margin-block-end: 2em !important;
}

Treat dark mode as a new context—not a filter

Do not mechanically invert the palette or apply universal rules such as “always use a lighter weight.” Re-evaluate the contrast, hierarchy, surfaces, states, and perceived weight of the actual typeface in the darker composition.

A copy-ready starter—with decisions still left for you

This is intentionally small. Replace the font families, colors, and scale with values that fit the project. The useful part is the structure: role-based tokens, bounded display sizes, readable measure, visible focus, and no claim that one snippet solves every interface.

:root {
  --font-sans: "Project Sans", system-ui, sans-serif;
  --font-display: "Project Display", Georgia, serif;
  --text-sm: 0.875rem;
  --text-body: 1rem;
  --text-lead: 1.25rem;
  --text-heading: clamp(1.75rem, 1.35rem + 1.4vw, 2.75rem);
  --text-display: clamp(2.5rem, 1.5rem + 4vw, 5.5rem);
  --leading-tight: 1.08;
  --leading-body: 1.6;
  --measure: 68ch;
}

html {
  font-family: var(--font-sans);
  text-size-adjust: 100%;
}

body {
  margin: 0;
  font-size: var(--text-body);
  line-height: var(--leading-body);
  color: #262626;
  background: #fafafa;
}

h1, h2, h3 {
  margin-block: 0;
  font-family: var(--font-display);
  line-height: var(--leading-tight);
  text-wrap: balance;
}

h1 { font-size: var(--text-display); }
h2 { font-size: var(--text-heading); }

p, li {
  max-inline-size: var(--measure);
}

p {
  margin-block: 0 1em;
}

:focus-visible {
  outline: 0.1875rem solid #005fcc;
  outline-offset: 0.1875rem;
}

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    scroll-behavior: auto !important;
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
  }
}

Standards and implementation sources

• MDN: clamp() — syntax, examples, and the accessibility note for fluid font sizes.
• W3C: WCAG 2.2 — contrast, resize text, reflow, and text-spacing requirements.
• web.dev: Best practices for fonts — loading, delivery, rendering, and the tradeoffs between font-display strategies.
• MDN: Variable fonts — registered axes, custom axes, and CSS controls.
• Next.js: Font optimization — current next/font setup for Google and local fonts.