Typography basics for interfaces

Type does most of the talking in an interface. Buttons, labels, paragraphs, error messages: all type. Get the basics right, the line length, the spacing, the size, the pairing, and reading feels invisible. Get them wrong and every sentence costs the reader a little more effort than it should, even if nobody can say exactly why. None of this is about picking a trendy font. It is a small set of measurable decisions that make text easy or hard to read, backed by decades of typesetting practice plus a few accessibility floors you cannot skip.

Measure: how long a line should be

The measure is the width of a line of text, usually counted in characters. Lines that run too long make the eye lose its place on the way back to the left edge; lines that run too short break reading rhythm with constant line changes. Butterick's Practical Typography, a widely cited reference for print and screen type, puts the workable range at roughly 45 to 90 characters per line, including spaces, or about two to three alphabets end to end.¹

A comfortable measure is one of the cheapest fixes available on a page. If body copy runs the full width of a wide screen, capping it, often somewhere in the middle of that range for a typical reading font, is usually the single biggest legibility improvement you can make, and it costs one line of CSS.

Line height: give text room to breathe

Line height, or leading, is the vertical space between lines. Too tight and lines blur together, especially for anyone reading fast or scanning; too loose and a paragraph falls apart into disconnected rows. Butterick recommends 120% to 145% of the point size for body text, and notes that the single or double spacing most word processors default to is a typewriter habit, not a value anyone chose because it reads well.² On interfaces that range is commonly nudged up a little further, to roughly 1.4 to 1.6 times the font size for body paragraphs, with tighter values reserved for large display type where lines are already short.

WCAG's Text Spacing criterion (1.4.12, Level AA) is worth reading carefully, because it gets misquoted often. It does not set your default line height. It requires something narrower: when a reader applies a specific set of overrides, line height to at least 1.5 times the font size, spacing after paragraphs to at least 2 times the font size, letter spacing to at least 0.12 times the font size, and word spacing to at least 0.16 times the font size, your layout cannot lose content or functionality because of it.⁴ In practice that means avoiding fixed-height text containers and clipped overflow on anything holding real copy. Meet that honestly and a comfortable default line height tends to come along for free.

Font size: start bigger than you think

Print gets read closer up and under better light than a phone on a bus. Butterick's guidance for web body text is 15 to 25 pixels, larger than the 10 to 12 points typical for print, precisely because screens are usually read from further away and vary far more in lighting and quality.³ Sixteen pixels sits near the bottom of that range and has become the de facto browser default for a reason: it is a safe floor, not a ceiling. Long-form reading, an older audience, or a dense information product are all reasons to start higher, not lower.

Apple's Human Interface Guidelines ties the same idea to a concrete, per-platform table of default and minimum text sizes, worth a look as one real-world reference point beyond the web:⁸

Build a type scale, not a guess

Once the body size is set, headings and secondary text should not get picked by eye, one at a time. A modular type scale multiplies a base size by a fixed ratio to generate every other size in the system, so the whole hierarchy stays proportionate instead of accumulating one-off numbers nobody can explain later. A common starting ratio is the Major Second (1.125) or the Major Third (1.25): pick a base body size, multiply up for headings and down for fine print, then round to whole pixels. Design systems like Material Design publish a full, named type scale you can adopt wholesale instead of deriving your own, though a published scale is usually hand-tuned rather than one strict geometric progression.⁷

:root {
  --text-caption: 12.8px;  /* 16 / 1.25    - captions, fine print */
  --text-body:    16px;    /* base         - body text, the anchor */
  --text-lead:    20px;    /* 16 x 1.25    - lead paragraph, H4 */
  --text-h3:      25px;    /* 16 x 1.25^2  - H3 */
  --text-h2:      31.25px; /* 16 x 1.25^3  - H2 */
  --text-h1:      39px;    /* 16 x 1.25^4  - H1 */
}

The exact ratio matters less than picking one and holding to it. A tight ratio like 1.125, Material's "Major Second," produces a subtle, dense hierarchy suited to data-heavy UI; a wider ratio like 1.25 or 1.333 produces more dramatic jumps suited to editorial or marketing pages. Four to six steps is enough for almost any product. More than that and the scale stops doing its job, which is making size decisions for you.

Pair families with intent: contrast by role, not by count

Every additional typeface is one more thing for the browser to load and one more thing for the reader's eye to reconcile. Most interfaces need at most two families: one for body and UI text, one for headings or a small amount of emphasis, and plenty of well-built products ship with a single family carried across several weights instead. If a second family earns its place, contrast it clearly against the first, a humanist sans against a slab serif, a grotesque against a serif with real stroke contrast, rather than picking two fonts that are almost, but not quite, the same.

• Reach for weight, size, color, and spacing before reaching for a third font. Hierarchy is a role each element plays, not a font it wears.
• If you are unsure a pairing works, remove one of the fonts. If the page still reads clearly, you did not need it.
• Match x-height and stroke contrast between paired families where you can. Wildly different x-heights at the same font size make one face look larger even when it is not.
• Keep body text in one family. Switching fonts mid-paragraph, even for emphasis, is one of the fastest ways to make a page feel unfinished.

Legibility details that quietly matter

A few properties of a typeface affect reading speed more than its overall style. X-height, the height of lowercase letters like x and o relative to the full cap height, drives how big a font feels and how legible it stays at small sizes; a taller x-height tends to read more clearly in a UI, where text is often small and viewed briefly. Letter spacing, or tracking, needs the opposite adjustment at different sizes: tightened slightly for large display type so letters do not float apart, opened slightly for small text or all caps so letters do not collide.

All caps deserves a specific warning. Reading relies partly on the shape of a whole word, and a run of capital letters is a rectangle with no shape left to recognize, which is why long stretches of all-caps text read more slowly than mixed case. Reserve all caps for short labels, buttons, and eyebrow text, never for a sentence, a paragraph, or a heading of any real length.

Web fonts in practice

A system font stack, the fonts already installed on a user's device, referenced by name, costs nothing to load and renders instantly, which is why it is worth defaulting to one for UI chrome even on a product that uses a custom font for headlines or brand moments. Every custom web font needs the same two things: a real fallback in the same font-family list, and a plan for the gap before it loads.

That gap has a name on either side of it. FOIT (flash of invisible text) is what happens when a browser hides text entirely until the custom font arrives; on a slow connection that can mean several seconds of a blank page where words should be. FOUT (flash of unstyled, or fallback, text) is the alternative: the fallback font shows immediately and the custom font swaps in once it loads, trading a brief, visible reflow for text the reader can actually see right away. Between an invisible page and a page that visibly settles into place, the second is almost always the better trade for anyone actually trying to read.

Performance and resilience point the same direction here: define a real fallback stack, load fonts with a strategy that favors showing fallback text over hiding it, and test the page with the custom font blocked entirely. If the fallback stack is close in size and spacing to the intended font, the swap barely registers. If it is not, that gap is a bug, not a footnote.

Resize and reflow: the honest accessibility floor

Two more WCAG criteria set a hard floor under everything above. Resize Text (1.4.4, Level AA) requires that text can be resized up to 200% without losing content or functionality, using nothing but the browser's own zoom.⁶ Reflow (1.4.10, Level AA) requires that content presented at a narrow, 320 CSS pixel width, roughly what 400% zoom on a standard desktop viewport produces, does not force scrolling in two directions at once, with narrow exceptions for things that genuinely need two dimensions, like data tables, maps, and images.⁵

Neither of these is hard to satisfy once the typography choices above are already in place. Sizes set in relative units, a measure that is capped rather than fixed, and layouts that stack instead of clipping will usually pass both with no extra work. The honest way to find out is to actually zoom your own page to 200% and narrow the viewport to 320 pixels before you ship, not to assume a framework already handled it.

Do this, avoid this

Checklist before you ship type

• Body text measure sits within roughly 45 to 90 characters at your default viewport width.
• Line height on body paragraphs is set explicitly, not left at the browser default.
• Base body size is 16px or larger on the web, bigger still for long-form reading.
• Heading sizes come from one scale and ratio, not chosen individually.
• No more than two type families are loaded, and each has a clear job.
• All caps is reserved for short labels, never full sentences or paragraphs.
• Every custom font has a system-font fallback and a font-display strategy set.
• The page is tested at 200% zoom and at a 320px-wide viewport without breaking.
• Text-spacing overrides (1.5x line height, 2x paragraph spacing, wider letter and word spacing) do not clip or overlap content.