Use font families

Built-in classes include font-sans, font-serif, and font-mono.

Each resolves to a font-family stack, not one guaranteed installed font. A stack gives the browser fallbacks when the preferred face is unavailable.

In Tailwind v4, add a project font to the theme in CSS:

@theme {
  --font-display: "Geist", ui-sans-serif, system-ui, sans-serif;
}

You can then use font-display:

<h1 class="font-display text-4xl font-semibold">Products</h1>

The theme variable creates a utility because its name uses Tailwind’s --font-* namespace. A regular :root variable is enough when you need a CSS variable but do not want to expand the utility API.

Defining the stack does not load the font. Add a correct @font-face, framework font integration, or hosted stylesheet separately. Match the declared weight and style to the actual files. Asking for font-bold when only a regular file is loaded can trigger synthetic bolding.

Font loading affects performance and layout. A fallback with very different metrics can cause text to reflow when the custom font arrives. Prefer a small number of necessary files, suitable caching, and a font-display strategy that keeps content readable. Consider privacy and availability before depending on a third-party font host.

Use fonts by role. A display face can distinguish headings while body copy keeps a familiar system stack. Monospace communicates code or aligned technical data; it is not automatically more readable for every label.

Your action is to add one local display font with a system fallback. Disable the font request in DevTools, compare layout shift and readability, and verify that every requested weight has a real font file.