How to create a UI type scale with CSS examples

A type scale should describe the interface hierarchy

A UI type scale is a small set of text roles with defined size, weight, line height, and intended use. It helps a page title feel like a page title and a field label feel like a label across the product. A mathematical ratio can help generate candidates, but the interface decides which values are useful.

Start with real content and the font files you intend to ship. A scale that looks elegant in an alphabet specimen can fail when a heading wraps, a table becomes dense, or a user increases text size.

This guide connects the role-based approach in TDP’s font-pairing article to an implementation you can review on a real screen.

Step 1. Establish body text

Begin with a paragraph and a form at a realistic reading size. A 16px body size with a 1.5 line height is an example starting point, not a universal standard. Different typefaces have different apparent sizes. Inspect the actual font and content before deciding that a number is correct.

Step 2. Define text roles

Choose a small set of roles your product needs. Avoid creating a new size for every screen. The sample below assumes a 16px root size; rem values follow the user’s root-size setting. Adjust it after testing.

Step 3. Specify more than font size

Document family, weight, line height, letter spacing, and usage. Two styles can share a size but serve different roles through weight and spacing. Avoid using a heading element only to make text large; semantic heading levels should follow the document structure.

:root { --text-body: 1rem; --text-label: .875rem; }
.body { font-size: var(--text-body); line-height: 1.5; }
.label { font-size: var(--text-label); line-height: 1.4; }
.page-title {
  font-size: clamp(2rem, 1.5rem + 2vw, 3rem);
  line-height: 1.15;
}

Step 4. Test responsive content

Use a long title, an error paragraph, and a table header. Inspect narrow layouts and increased text size. Make containers flexible enough to accommodate wrapping. If text clips, fix the layout or sizing rule rather than hiding the overflow. The live specimen lets you explore size, weight, and line height; it is a visual starting point, not a replacement for testing your product.

Step 5. Test user spacing overrides

W3C’s text-spacing criterion requires content to remain usable under specified spacing overrides. It does not require your default typography to use those values. Check increased line, paragraph, letter, and word spacing without fixed-height text containers cutting off content.

Worked example: define roles for a settings page

A settings page usually needs fewer text roles than a marketing site. Start with the page title, section heading, body text, label, and supporting text. Add a distinct role only when it expresses a meaningful relationship.

Do not rely on size alone. Weight, spacing, and placement also establish hierarchy. A small label can remain clear through consistent positioning, while an oversized heading can disrupt a dense task.

Use ratios as a draft, then edit the scale

A modular ratio can produce an initial sequence, but you do not need to use every generated value. Select the sizes that solve real roles and remove near-duplicates that create maintenance without a visible benefit.

Compare the scale with short and long content. If a heading wraps awkwardly, inspect the container width and wording as well as the font size. Shrinking all headings may hide the symptom while weakening the hierarchy elsewhere.

Specify line height and weight alongside size

A token called heading-large is incomplete if consumers choose arbitrary weights and line heights. Record the full text style. Use unitless line height where appropriate so it scales with the text, and test the actual rendered result.

For example, a body role might use a different line-height relationship from a large heading. That is a design choice to verify in context, not a universal number to apply to every language and font. Keep controls flexible enough to accommodate wrapping and user text adjustments.

Make responsive changes by role

A page title may need a smaller size on a narrow screen while body text remains stable. Do not scale every role down proportionally just to fit a layout. Revisit the composition, wrapping, and available space before reducing readability.

Test at narrow widths and with zoom. Check that headings still form a sensible order and that controls do not clip their labels. Visual heading styles and semantic heading levels are related but distinct: choose document structure for meaning, then style it appropriately.

Keep the scale connected to code and examples

Use named roles in the component system and show each role in a specimen with realistic content. When a new size appears in a pull request, ask which existing role it extends or why a new role is necessary.

A useful review compares the page as a whole. If everything is bold or large, hierarchy disappears even when every value comes from a token. Pair this guide with visual weight and spacing to review the relationships together.

Completion checklist

• Every style has a role and usage rule.
• Font weights exist in the delivered font files.
• Long content and translations can wrap.
• Headings preserve document structure.
• Text resizing and spacing overrides do not hide content or controls.

Common questions

Should every size follow a mathematical ratio?

A ratio can make a starting scale coherent, but a product may need adjustments for dense labels or specific reading tasks. Document intentional exceptions.

How many heading sizes do we need?

Use enough to express the content hierarchy clearly. Avoid adding a visual level when the page has no corresponding structural distinction.

Sources

• W3C: Text Spacing
• MDN: font-weight