Choosing Between Different Fonts: A Typography Guide

A product's typeface gets picked once, usually early, usually by whoever happened to be holding the file. Every screen built afterward inherits the decision. Very few design choices have that property — colors get retuned and components get rebuilt, but changing type touches every line of text in the product simultaneously, so the original choice tends to outlive any memory of why it was made.

Which is an argument for making it on evidence. A larger share of the decision is measurable than the usual review conversation suggests: legibility properties you can check in an afternoon, four accessibility numbers with actual right answers, a file size your users pay for on every visit. Judgment handles the rest, and it works better once the measurable part has narrowed the field. Type is also the instrument most of visual hierarchy gets played on, so the consequences run well past the letterforms.

Typeface, font, family: the distinction that still matters

A typeface is the design. A font is one instance of it at one weight, width, and style. Helvetica is a typeface; Helvetica Bold Italic at 16px is a font. In metal type this was a physical distinction — you owned drawers of one and cases of the other — and the software collapsed it, which is why the words are used interchangeably everywhere including in this article's title.

It still matters in one practical place: when you say a project uses "two fonts," you might mean two typefaces, or you might mean two of the twelve weights inside one family. Those are wildly different decisions, and the second one is almost always the better version of the first.

Why different fonts read differently

Here is the finding that clears the most argument off the table: in well-set text, serif and sans-serif perform about the same. The eye-tracking and reading-speed literature has been unable to produce a consistent legibility gap between the two categories, on screen or on paper. The eye-tracking work summarized here is one of many studies finding no significant difference, and reviews of the wider body of research reach the same place. "Sans-serif is more legible on screens" was a reasonable rule when screens were 72 DPI. It is now folklore.

The differences that do show up are between individual typefaces, not between categories, and they come from a handful of structural properties:

• x-height — the height of a lowercase x relative to the capitals. A large x-height keeps a typeface readable at small sizes, which is why interface typefaces almost all have one, and why a display face set at 13px looks anemic.
• Counters and apertures — the enclosed and partly enclosed white shapes inside letters. Tight, closed apertures make c, e, s, and a converge at small sizes and at distance.
• Character disambiguation — whether capital I, lowercase l, and the digit 1 are distinguishable, and whether 0 is slashed or dotted. This stops being a nicety the moment your product displays serial numbers, coupon codes, or passwords.
• Weight range and optical sizing — whether the family gives you enough steps to build a hierarchy, and whether it was drawn to hold up at 12px as well as 60px.

Those four are checkable in an afternoon. Whether the typeface "feels premium" is not.

The same evidence-versus-folklore split shows up in a place with higher stakes. Fonts marketed as dyslexia aids are widely assumed to help, and the closest thing to a controlled test found the opposite: an alternating-treatment study of OpenDyslexic with elementary students identified as having dyslexia found no improvement in reading rate or accuracy against Arial and Times New Roman, with students reading slightly slower and less accurately in the specialized face. If you want to help dyslexic readers, spend the effort on size, spacing, line length, and contrast, all of which are supported by the standards below.

How many different fonts should a design use?

Two typefaces is the working answer for nearly every product, and one is a completely legitimate choice.

The reason is not aesthetic restraint. It's that every additional typeface is a second axis your hierarchy has to be legible along, and hierarchy built from size and weight inside one family is easier to make consistent than hierarchy built from which typeface this is. A single well-drawn family with six weights will produce more usable distinctions than three families with two weights each, and it will do it without a stranger having to learn your system to read a screen.

Where a second typeface earns its place:

• A display face for marketing surfaces, paired with a workhorse for the product interface.
• A monospace for code, IDs, diffs, and anywhere character alignment carries meaning.
• A distinct face for long-form editorial content, when the reading experience is genuinely different from the app's.

Three or more different fonts in one interface is usually a merge artifact — a design system that absorbed a rebrand, or two teams' work that never reconciled. It reads as noise even when nobody can name why.

Pairing different fonts without guessing

The advice "pair a serif with a sans" is not wrong so much as insufficient; it tells you nothing about which serif and which sans. Two rules do more work:

Contrast enough that the pairing looks deliberate. Two humanist sans faces of similar weight and x-height set next to each other look like a mistake, not a decision. If a reader has to check twice whether two things are the same typeface, the pairing has failed.

Match the invisible metrics. Compare x-heights and cap-heights at the same point size. Faces with very different x-heights need different optical sizes to feel balanced, and if you don't compensate, your heading will read as smaller than a body paragraph set at half its size.

The lowest-risk pairing is a superfamily — one design with matching serif, sans, and sometimes mono cuts drawn to share metrics. IBM Plex, Source Sans/Serif, and Noto all offer this. The pairing problem is solved for you by the person who drew the letters.

The numbers: what accessibility standards actually require

Four constraints in WCAG bear directly on type, and they are the only part of this decision with a right answer.

Contrast. WCAG 1.4.3 sets a minimum of 4.5:1 for body text at Level AA, and 3:1 for large text — defined as 18pt, or 14pt bold, which works out to roughly 24px and 18.66px bold. Light-gray body copy on white is the single most common failure, and it is almost always defended as a brand decision.

Resize. WCAG 1.4.4 requires text to scale to 200% without loss of content or function. This is what fixed-height containers and px-locked layouts break. Test it by zooming to 200% and looking for text that clips, overlaps, or disappears behind a sticky header.

Text spacing. WCAG 1.4.12 says a user must be able to override your typography to line height 1.5× the font size, paragraph spacing 2×, letter spacing 0.12em, and word spacing 0.16em — without losing content. Tightly-tuned type that shatters under those overrides fails the criterion regardless of how good it looks at your settings.

Line length. Not a WCAG requirement at AA, but 1.4.8 recommends no more than 80 characters per line, and the typographic convention of roughly 45–75 characters per line points the same way. This one is nearly free: set a max-width in ch units and stop thinking about it.

Read those four as a floor, not a target. They are the size below which people start failing to read the thing.

What a font costs to load

A typeface is also a network asset, and the design decision quietly sets a performance budget. Every weight and style is a separate file unless you plan otherwise.

Variable fonts are the answer to that. A single file carries a continuous range along one or more axes — weight, width, optical size — so a family that used to cost six requests costs one. Any product using more than about three weights of the same family should be checking whether a variable version exists. Browser support has been universal for years.

font-display decides what the user sees while the file is in flight. The default is a blocking period where text is invisible; swap shows a fallback immediately and swaps when the webfont lands; optional gives the font a very short window and otherwise sticks with the fallback for that page load. swap is the usual pick for body copy; optional is the right choice when the layout shift on swap would be worse than never getting the font. Choosing neither is still a choice, made by default.

Self-host. Serving fonts from a third-party CDN used to be justified by a shared browser cache across sites; browsers partitioned that cache years ago, so the visitor downloads your copy either way, plus an extra DNS lookup and connection. Self-hosting also removes a privacy dependency and a third-party outage from your critical rendering path.

Subset. A Latin-only subset of a font that ships Cyrillic and Greek can cut the file substantially. If you don't serve those languages, you're paying to transmit glyphs nobody will render.

Also: match your fallback's metrics. size-adjust, ascent-override, and the @font-face descriptors around them exist so the fallback occupies the same space as the real font, which is what turns a jarring reflow into an unnoticeable swap.

Licensing, briefly, because it bites

Type is licensed, not bought, and the licenses are segmented by use: desktop, web, app, and sometimes broadcast or logo use, each metered differently — by installed seats, by monthly pageviews, by app installs. A desktop license that lets a designer set comps in Figma frequently does not permit serving the file from your web server.

The open route avoids all of it. The SIL Open Font License covers most of Google Fonts and a large share of the best contemporary faces, permits commercial use and self-hosting, and asks essentially one thing in return: don't sell the fonts on their own. For most products it is not a compromise, it's just the answer.

Doing it in order

Constraints come before candidates. Which languages and scripts you serve, which weights you will genuinely use rather than admire, the smallest size the face has to survive, and whether numerals have to line up in a table — that list eliminates most of the internet's typefaces before you have looked at one.

Then shortlist three, and reject on structure before feel: x-height, apertures, whether Il1 and 0O are distinguishable, how many weights you get.

Now set real content in them. Not lorem ipsum — your longest button label, your worst product name, a table of numbers, the error message with the support link in it. Different fonts break in different places and placeholder text conceals every one of them. This is the step teams skip, and it's the step that catches the problem you would otherwise ship.

Run the four numbers. Weigh the files, check for a variable cut, set font-display, subset.

Then write it into the design system as a type scale rather than a set of values people copy off a Figma layer. Decisions that live only in a file get relitigated; decisions that live in tokens get inherited.

Frequently asked questions

How many different fonts should a website use?

Two typefaces, or one. Build hierarchy from weights and sizes inside a family before reaching for a second family, and treat three or more as a signal that something needs consolidating.

Are serif fonts harder to read on screens?

No. Reading-speed and eye-tracking research has consistently failed to find a meaningful legibility difference between serif and sans-serif in well-set text. The variation that matters is between individual typefaces — x-height, aperture, weight range — not between the two categories.

What font size should body text be?

16px is the sensible default for web body copy, and it's also the browser default that users may have deliberately changed. Anything under about 14px starts excluding people. What matters more than the number is that the size is set in relative units so it scales with the user's preference and survives the 200% zoom requirement.

What is the difference between a typeface and a font?

The typeface is the design; a font is one specific instance of it at a given weight, style, and size. Everyday usage treats them as synonyms, which is fine until you're specifying exactly what a project needs to license or load.

Do dyslexia-specific fonts help?

The evidence says no. A controlled study of OpenDyslexic with dyslexic elementary students found no improvement in reading rate or accuracy compared with Arial and Times New Roman. Generous size, line spacing, short line lengths, and strong contrast have better support.

Should I use Google Fonts or self-host?

Self-host the files. Google Fonts is an excellent library and its licensing is permissive, but the browser-cache advantage that once justified serving from the CDN disappeared when browsers partitioned their caches by site. Download, subset, and serve from your own origin.

The part that isn't a checklist

Everything above narrows the field. It doesn't pick the winner, and it shouldn't — the last step of choosing between different fonts is a judgment about what the product is supposed to feel like, and that judgment is real work rather than an obstacle to it.

The difference is that a decision made after the constraints is defensible. When someone asks in six months why the interface uses this face, the answer is a list of things it does — holds up at 13px, disambiguates its numerals, ships as one variable file, clears contrast at your brand's gray — rather than a memory of which option looked best on a projector.