Design a Responsive Type Scale That Survives Real Content

AI-generated conceptual illustration; not a product screenshot, measured result, or factual diagram.

A type scale looks finished when six headings sit neatly above a sample paragraph. It starts earning its place when a customer adds a 19-word title, someone enlarges their browser text, and the same card appears in a narrow sidebar.

Build your scale around those situations. The useful deliverable is a small set of text roles, the CSS that implements them, and a page of awkward content that keeps the system honest. A mathematical ratio can help you explore sizes, but it cannot decide whether a product name wraps well or a paragraph is comfortable to read.

Start with text roles and real sentences

Collect examples from the product before choosing sizes. For a small editorial site, a sensible starting inventory is body copy, supporting text, a card heading, a section heading, and a page title. Add a display role only if the site genuinely needs a larger promotional treatment. Each role should have a reason to exist beyond filling a gap in a number sequence.

For every role, save a typical example and a difficult one. Use actual content when available. Otherwise, write realistic substitutes that include long names, dates, acronyms, punctuation, and multi-line links. A sentence such as “Tools for making things” tells you little about a card that may later contain “A practical guide to photographing reflective objects in a one-bedroom apartment.”

Keep semantic structure separate from appearance. A page's heading levels should describe its organization; a visual token describes a treatment. A card heading can use a restrained style without becoming a paragraph, and a section should not jump from h2 to h4 simply because the h4 happens to look right. Review the outline and the visual hierarchy as two related decisions.

Choose a readable body before a dramatic title

Start with a paragraph in the intended font, at the intended content width. Try a body size of 1rem and a unitless line height around 1.6 as a design starting point, not a universal accessibility threshold. Adjust while reading several paragraphs, not while comparing isolated letters. A dense technical manual and a spacious essay can reasonably land in different places.

Make width part of the experiment. The same type size can feel tiring across a very wide column and cramped inside a small card. A maximum width such as 65ch is a useful initial constraint for a prose block, but ch is not a promise of exactly 65 characters on every line. The font and the mix of letters still matter. Keep this as a tunable design value.

Inspect the smallest supporting text next. Dates, captions, error explanations, and bylines may carry information the reader needs. Do not shrink them automatically to make the hierarchy more obvious. Try weight, spacing, placement, and color choices that still meet the project's contrast requirements before sacrificing legibility.

A worked scale for a fictional resource library

Imagine a site called Fieldnotes that publishes practical design guides. It has article pages, a three-column listing on wide screens, and a single-column listing on phones. The examples and values below are an original design exercise, not results from a tested production system.

Fieldnotes uses five roles: supporting text at 0.9375rem, body at 1rem, card headings at 1.25rem, section headings from 1.5rem to 2rem, and page titles from 2rem to 3.25rem. The body and card roles stay steady; only the larger headings grow with the viewport. This gives the designer fewer moving parts while leaving room for a more expressive article header.

:root {
  --text-support: 0.9375rem;
  --text-body: 1rem;
  --text-card: 1.25rem;
  --text-section: clamp(1.5rem, 1.25rem + 1vw, 2rem);
  --text-title: clamp(2rem, 1.375rem + 2.5vw, 3.25rem);
}

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

.prose {
  max-inline-size: 65ch;
}

.page-title {
  font-size: var(--text-title);
  line-height: 1.12;
  max-inline-size: 22ch;
}

.section-title {
  font-size: var(--text-section);
  line-height: 1.25;
}

.card-title {
  font-size: var(--text-card);
  line-height: 1.3;
}

.supporting-text {
  font-size: var(--text-support);
  line-height: 1.5;
}

The three arguments of clamp are the minimum, preferred value, and maximum. Here, the middle expression combines a root-relative component with a viewport-relative component. The minimum prevents an unusually small viewport from reducing the title indefinitely; the maximum stops it from continuing to grow on a very wide display. See MDN's clamp reference for the function's behavior.

With a 16px root size, the title expression reaches 32px at a 400px viewport and 52px at a 1200px viewport. At 800px it yields 42px. These are arithmetic checkpoints for this example, not target devices or guaranteed sizes under different user settings. Changing the root size changes the relationship. Using rem inside a fluid expression is useful, but it does not by itself prove that the finished interface handles zoom correctly.

A specimen you can copy

Use the following fictional Fieldnotes copy with the CSS above. Keep these strings unchanged while comparing widths; otherwise a shorter replacement can hide a layout failure.

Here is a minimal semantic title specimen. Add it inside the page's main content area, then add your real cards and controls for interaction checks. The title is text rather than an image, so readers can select it and apply their own text settings.

<header class="prose">
  <h1 class="page-title">A practical guide to photographing reflective objects in a one-bedroom apartment</h1>
  <p>Start with one light, one surface, and a repeatable way to compare reflections.</p>
  <p class="supporting-text">Updated 8 October 2026 · 12-minute read</p>
</header>

Viewport units can offset part of a zoom increase. For this title, starting at a 1200 CSS-pixel viewport gives 52px; at 200 percent page zoom, a 600 CSS-pixel layout gives 37px, displayed at roughly 74px relative to the initial screen scale. That is about 142 percent of the starting title size, not 200 percent. This arithmetic does not itself establish a WCAG failure: the finished page must support a mechanism that reaches double the starting text size without losing content or functionality. Check actual enlargement as well as clipping; do not treat a browser's zoom percentage as proof that fluid text doubled.

Decide what should respond to the container

A page title usually lives in a predictable part of the layout. A reusable card can appear in a full-width list, a two-column grid, or a sidebar on the same viewport. That is a reason to be cautious about giving every role a viewport-based size.

For Fieldnotes, a fixed root-relative card heading is a deliberate first choice. If a narrow card is awkward, inspect padding, column width, and title length before introducing a second fluid formula. The cards may need to stack earlier. The component may need a wider minimum column. A different font weight may make the heading feel less crowded without making it smaller.

Sometimes a container-aware treatment is appropriate. Document that as a component rule, with its own test cases, instead of quietly replacing a shared token in one stylesheet. Otherwise the same role gradually acquires several incompatible meanings and later changes become difficult to predict.

Make an awkward-content specimen

A useful specimen is a real page built from the real components. A design-file frame is valuable for exploration, but it will not reveal every browser behavior. Put these cases together so the team can revisit them after changing a font, token, or layout:

• A short page title and a title that fills three or four lines.
• A card with a long proper name, and one with a short single-word heading.
• A paragraph with links, bold text, italic text, numbers, and parentheses.
• A caption long enough to wrap beside or beneath an image.
• A navigation label that is longer than its English equivalent, when localization is part of the product.
• A long URL or identifier in the component that may actually display it.
• A list, a quotation, and a form explanation using the same body role.

For a long URL, choose a wrapping strategy in the relevant component. Do not apply aggressive breaking to every heading just to fix one machine-generated string. Likewise, avoid manually inserting line breaks into editorial titles to rescue one screenshot. Those breaks can become awkward when the font loads, the viewport changes, or the wording is translated.

Include the intended fallback font in your review. Temporarily disabling the web font lets you see whether a heading's extra line causes overlap or hides a control. A system that only works with the exact font loaded at the exact moment is a fragile system.

Test resizing, reflow, and text spacing separately

These checks overlap, but they answer different questions. Record what happened in the actual page rather than marking “accessible typography” after looking at one zoomed screenshot.

First, enlarge text and check that content and controls remain usable. WCAG's Resize Text guidance describes resizing text up to 200 percent without loss of content or functionality, with specified exceptions. Watch for clipped labels, hidden helper text, and buttons whose fixed heights cannot accommodate another line.

Next, check narrow reflow. WCAG's Reflow guidance addresses presenting content without loss or two-dimensional scrolling at specified dimensions, including a width equivalent to 320 CSS pixels for vertically scrolling content, subject to exceptions. A common way to exercise that case is 400 percent browser zoom from a 1280 CSS-pixel-wide viewport. It is a layout check as much as a font-size check.

Finally, override text spacing. WCAG's Text Spacing guidance covers avoiding loss when users set line height to at least 1.5 times the font size, paragraph spacing to at least twice the font size, letter spacing to at least 0.12 times, and word spacing to at least 0.16 times. These are override conditions to accommodate, not a requirement to ship every paragraph with those exact default values.

Inspect the resulting page with a keyboard as well. If a wrapped label pushes the next control down, the focused control still needs to be visible and usable. Fixing a text problem by hiding overflow may remove the visible symptom while making the interaction worse.

Diagnose the failure before changing the scale

When a title feels too large, ask what failed. If one long word spills outside its box, the immediate problem may be wrapping. If every heading in a sidebar dominates its card, the role or component width may be wrong. If an article feels exhausting, the issue may be line length or paragraph spacing rather than the body size.

In the fictional Fieldnotes review, suppose a long title pushes the article summary below the initial viewport. That alone is not a defect: readable content can occupy space. The useful questions are whether the title communicates the topic, whether the page still has a clear hierarchy, and whether the layout handles the length without overlap. A product requirement to keep a particular action visible should be resolved explicitly, not hidden inside an unexplained font reduction.

Prefer one well-understood adjustment over several compensating overrides. Widening the title measure slightly may solve an awkward stack. Reducing the maximum size may help across many long titles. Shortening a genuinely wordy title may improve the content itself. Save the rejected options briefly so the next reviewer understands the tradeoff.

Hand off rules that someone else can maintain

Record the role name, intended uses, size or formula, line height, and relevant component constraints. Add an example of when the role should not be used. For instance, “page-title is for the primary title in the article header; cards use text-card even when their heading element is h2.” That sentence prevents more confusion than another column of pixel values.

Keep the specimen page next to the implementation and link to it from your design documentation. If you are building the wider system around these decisions, the existing brand-guidelines guide is a related starting point for documenting reusable choices.

Before calling the scale ready, verify five things: realistic copy fits without hiding information; body text remains comfortable at its intended width; small text still earns its size; zoom and spacing overrides preserve content and controls; and each visual role has a clear owner in the code. Then keep the awkward examples. They are the most useful part of the scale when the content changes.