Font pairing for UI mockups

Published: 2026-09-05

How to pair heading and body typefaces, build a modular scale, check CLS with fallback overlays, and export CSS—without uploading mock copy.

Font pairing is choosing two (sometimes three) typefaces that share a job on the page: a heading face for hierarchy and brand, and a body face for long reading. Good pairs feel intentional—contrast in style or weight, harmony in proportion—without fighting each other for attention.

LocalTools’ Font pairing workbench lets you try Google Font families side by side, tune sizes and variable axes, generate a modular scale, and overlay a system fallback to spot layout-shift risk. Preview and your sample text stay in the tab; stylesheets load from Google Fonts only after you pick a family.

What makes a pair work

Role Typical choice Why
Heading Display, serif, or distinctive sans Personality and clear hierarchy at large sizes
Body Neutral sans or readable serif Even color on the page, steady line wraps
UI chrome Often the body family (or a close relative) Labels and buttons should not introduce a third “voice”

Useful contrast patterns:

  • Serif headings + sans body — classic editorial: soft display vs clean reading.
  • Geometric sans + humanist sans — both sans, but different letter shapes so the pair still reads as two roles.
  • Same family, different weights — one variable or multi-weight family for both roles when brand needs quiet consistency.

Avoid pairs that are almost identical (two similar geometric sans at the same weight)—the page looks accidental. Also avoid three loud display faces fighting in one viewport.

For filler paragraphs while you judge rhythm, generate local placeholder with Lorem Ipsum—see Lorem ipsum for mockups.

Size hierarchy: modular scales

A modular scale multiplies a base size by a fixed ratio so every step feels related:

Ratio name Factor Feel
Minor second 1.067 Subtle (dense UIs)
Minor third 1.2 Soft hierarchy
Major third 1.25 Common UI default
Perfect fourth 1.333 Clear steps
Perfect fifth 1.5 Bold jumps
Golden ratio 1.618 Dramatic (marketing heroes)

Example with base 16px and major third (1.25): roughly 16 → 20 → 25 → 31 → 39px. Assign one step to body, a higher step to H2, another to H1—then stick to that ladder in the mock.

Fluid layouts often wrap those px steps in clamp() between viewports. See CSS clamp() and fluid type once the static scale looks right.

Weight, italic, and variable axes

Static fonts ship discrete weights (400, 700). Variable fonts expose continuous axes such as:

  • wght — weight (often 100–900)
  • wdth — width (condensed ↔ extended)
  • slnt — slant (optical italic-like lean without a separate italic file)

Use continuous weight for mock fine-tuning; ship only the axis ranges you need so download size stays honest. Italic as a separate style still matters for emphasis in body copy—do not rely on slant alone for semantic <em> unless you have checked the design system.

Fallbacks and CLS (layout shift)

When a web font swaps in after a system font, glyph widths often differ. Text reflows; Cumulative Layout Shift (CLS) scores suffer.

Practical habits:

  1. Overlay a system stack (e.g. Arial) under the web font and compare outline widths before you commit.
  2. Prefer font-display: swap (or optional when branding can wait) so text stays visible; accept a brief metric mismatch rather than invisible text.
  3. Match x-height and approximate width with size-adjust / fallback @font-face metrics when you self-host—export templates are a starting point, not a finished metric-matched stack.
  4. Keep line-height and letter-spacing stable across the swap so vertical rhythm does not jump twice.

The workbench’s fallback overlay is for seeing mismatch in the canvas; production still needs real fallback CSS and, for critical paths, measured font-face overrides.

Contrast and color still apply

A beautiful pair fails if body grey on white sits under 4.5:1. Check text and UI pairs with the WCAG Contrast Checker and contrast ratios AA vs AAA. Type size from the modular scale feeds into whether WCAG treats copy as “large text.”

Privacy note

Mock headlines and product blurbs do not need to leave your machine. Prefer a client-side workbench so sample copy stays local (Why “local only” matters). Loading a Google Font stylesheet when you select a family is expected network use for that font—not an upload of your draft text to LocalTools.

Practical workflow

  1. Pick a heading family with clear personality at large size.
  2. Pick a body family optimized for paragraphs; set weight, size, line-height, and letter-spacing.
  3. Generate a modular scale from a base size and ratio; apply steps to heading and body.
  4. Enable variable axes if the family supports them; stress-test real numerals and punctuation in the canvas.
  5. Turn on fallback overlay and watch for width mismatch; adjust size or choose another pair if reflow looks severe.
  6. Export Google Fonts <link> tags, CSS variables, and an @font-face template with font-display: swap.

Try it locally

Open the Font pairing workbench:

  1. Search or type Google Font family names for heading and body (stylesheets load only when you apply a font).
  2. Tune weight, size, line height, and letter-spacing; enable variable axes when available.
  3. Use Modular scale to compute steps and apply one to heading or body.
  4. Toggle Overlay fallback to compare against a system stack.
  5. Open CSS / HTML export and copy what you need into the project.

Your canvas text stays in this browser tab; LocalTools does not store font-usage analytics.

Related reading

← All learn articles