Web typography: font selection, readability and proportions

A typeface can look excellent on a brand poster and become tiring in a long technical article. Websites also contain forms, tables, short labels and changing viewport sizes. Choosing a font is therefore the beginning of a system rather than a final judgement of taste.

This guide develops a testable workflow for a fictional consultancy with service pages, guides and a contact form. The examples are original editorial proposals. CSS values are starting points for experiments rather than universal guarantees of readability.

1. Identify the actual text tasks

Begin by listing the kinds of text the site needs. A company website may require large titles, body copy, navigation, field labels and prices. A technical publication adds references, data tables and source code. Those tasks place different demands on the same type family.

Prepare three realistic samples for the consultancy: a short service description, a technical passage with subheadings and a form containing a longer error message. Placeholder Latin does not reproduce the word lengths, sentence structure and special characters of the eventual language.

Record the supported languages as well. Accents, currency symbols and specialist characters need to exist in the actual font. A family may cover the primary language while translated names trigger an inconsistent fallback for individual characters.

The task inventory helps narrow the selection. A condensed face can work for large headlines without being the right body font. An additional family is useful only when its separate role justifies the extra design work, resources and maintenance.

2. Assess letterforms in context

Readability is not determined solely by whether a typeface has serifs. Apparent lowercase height, counters, stroke weight and character differentiation influence the result. Their interaction with size and display conditions matters.

Test similar characters deliberately: uppercase I, lowercase l and the digit 1, as well as uppercase O and zero. Poor differentiation can cause practical mistakes in serial numbers, invoices and access details. The same weakness may be less noticeable in a narrative article.

Include long words and specialist vocabulary. The typeface should work beyond an isolated brand name. Headings containing long compounds require more attention than a specimen made entirely of short English words.

Assess the selection on actual devices. A large high-resolution screen may render fine details differently from a small mobile display. A design-tool screenshot does not replace the browser using the font file that visitors will actually receive.

3. Treat size as part of a relationship

A statement such as “16 pixels is always correct” is too simple. Apparent size varies between typefaces. Viewing distance, text density and situation also matter. Initial values should therefore be checked with the intended content.

Relative units support a coherent system. A body size can use rem, with related heading levels around it. Do not restrict browser enlargement. An extra size control on the site is not a replacement for functional browser zoom.

The W3C explanation of text resizing discusses enlargement up to 200 percent without loss of content or functionality under the relevant criterion, apart from its stated exceptions. Include controls and labels in the practical review.

Fixed heights are a common failure point. Text enlarges while a card header stays the same height and clips the next line. Prefer a structure that can accommodate its contents, then check alignment across the full component group.

4. Set line length and line spacing together

Very long lines can make the next line hard to locate. Very short lines interrupt a thought with frequent breaks. No single width fits every font, language and content type, but a bounded reading measure is a useful starting point.

The ch unit can help establish that boundary. It relates to a character metric rather than guaranteeing an exact number of arbitrary letters per line. Inspect real paragraphs within the chosen width.

.article-text {
  max-width: 66ch;
  font-size: 1.0625rem;
  line-height: 1.65;
}
.article-text p { margin-block: 0 1.25em; }
.article-text h2 { margin-block: 2em .6em; }

These values are an experiment, not a finished standard. Change a small number of related parameters at a time. A wider measure may call for a different line height. Excessive spacing does not automatically repair an unsuitable line length.

Read several paragraphs rather than judging a single sentence. Longer material reveals whether the rhythm becomes tiring or paragraph relationships become unclear. Reference lists and bullet points also need their own place in the same system.

5. Develop a manageable type scale

Do not explain importance with an arbitrary number of sizes. Start with body text, supporting information, section headings and a main title. Add another level when a genuine role requires it.

Sizes can adapt fluidly to viewport space. A rule using clamp() bounds a variable value between a minimum and maximum. Avoid sizing based only on viewport width in ways that undermine a person's attempt to enlarge text.

HTML heading levels remain a content decision independent of apparent size. A particular component may justify a different visual treatment, but the underlying hierarchy should still make sense. Semantic organisation and presentation are related decisions rather than interchangeable ones.

6. Limit weights and emphasis

A large collection of available weights invites unnecessary variation. Many sites need only a few clearly distinguishable weights. Additional cuts need a role. If every other sentence is bold, bold text stops communicating a useful distinction.

Use emphasis for a meaningful statement. A specialist term may be highlighted at its introduction or a prerequisite may need attention. Combining bold, italic, colour and underlining repeatedly in a short paragraph often creates noise rather than clarity.

Verify that the requested weight is actually provided by a font file or variable-font range. Otherwise the browser may synthesise an approximation that differs from the intended design. Declared weights and delivered resources should agree.

Links need a recognisable treatment. An underline can indicate the function in addition to colour. If underlining is used decoratively elsewhere, prevent confusion with interactive content. The convention should remain understandable across the site.

7. Review numbers and tables separately

Numbers need different attention from continuous prose. Prices, times and measurements should be easy to compare. Suitable tabular figures can align digits in columns, provided the chosen font contains the feature.

.numeric-column {
  font-variant-numeric: tabular-nums;
  text-align: right;
}
.code-example {
  font-family: ui-monospace, monospace;
  overflow-x: auto;
}

Alignment does not replace units. A numerical column without a recognisable currency or measurement remains ambiguous. Tables also require clear relationships with their headers. Typography supports that information structure rather than creating it by itself.

The consultancy specimen includes sample prices, telephone numbers and longer project identifiers. These are test values rather than actual offers. Such cases expose awkward character forms before real business information is entered.

8. Load fonts reliably

A web font is a resource that needs delivery. Until it becomes available, the browser follows a rendering strategy. Switching between a fallback and the web font can change line breaks and component dimensions.

The MDN font-display reference explains the available behaviours. Do not choose a setting solely because its name sounds desirable. Assess how text visibility and later switching affect the actual project.

@font-face {
  font-family: "Project Sans";
  src: url("/fonts/project-sans.woff2") format("woff2");
  font-style: normal;
  font-weight: 400;
  font-display: swap;
}
body { font-family: "Project Sans", system-ui, sans-serif; }

The file name is a placeholder for an existing, appropriately licensed resource. Do not copy the rule unchanged while leaving a nonexistent address. Deliver only needed variants and check that any subset covers the required languages.

The web.dev font performance guidance discusses delayed rendering and layout shifts caused by font changes. A meaningful review therefore includes an empty cache, delayed font responses and fallback rendering rather than only a warmed-up page.

9. Design fallback rendering as an expected state

A fallback is not an irrelevant error state. It may appear over a slow connection, with blocked resources or during initial rendering. Its proportions should keep the content reasonably stable.

Inspect large headings, menu labels and form buttons with the web font disabled. A menu that fits only after the font changes is fragile. Fast tests can conceal that dependency.

People may also prefer their own font or spacing settings. A robust interface preserves information and interaction under those changes. Every resulting appearance does not need to be pixel-identical to the designer's original view.

Document the fallback family and known differences. That information makes a later font replacement a deliberate system change rather than a silent file swap without consideration of the consequences.

10. Allow adaptable spacing

The W3C text spacing explanation describes testing changed line, paragraph, letter and word spacing. Its values are not mandatory defaults for every design. The relevant requirement concerns preserving content and functionality when the stated overrides are applied.

Fixed cards and navigation bars can fail under increased spacing. A title that previously fitted needs another line. The label should not be clipped or overlap a neighbouring control.

Use a temporary, bounded test stylesheet and remove it after the check. Correct the affected components. Shrinking every text style would not be an appropriate response to someone requesting more readable spacing.

Include non-breaking spaces and deliberately grouped units in the review. They can be useful but should not create unnecessary overflow on narrow screens. Inspect actual wrapping rather than assuming the rule alone produces the desired result.

11. Establish licensing and delivery before embedding

A downloaded font is not automatically licensed for every use. Web embedding, app distribution and print can have different conditions. Check the actual source and retain the terms for the intended use.

Self-hosting is also a delivery decision involving paths, caching and future updates. External services introduce their own integration details and require the project's relevant legal assessment. A visual preference alone does not resolve those questions.

This guide therefore does not recommend an unverified individual family. First assess whether the existing brand font is suitable and licensed for web use. Search for an additional family when a specific unmet requirement remains.

Keep the licence evidence with the intended files. Record the source, version, permitted use and deployed variants in the project documentation. That makes later changes easier and reduces the risk of replacing a resource with a differently licensed edition.

12. Build a realistic typography specimen

A specimen gathers important text tasks in one place. Include a long title, several connected paragraphs, a list, a form and a small table. Prepare the material in the actual supported languages.

Save results with a date and font version. Later changes can be reviewed against the same cases. Record concrete observations rather than simply saying the typography looks good; that does not explain whether the longer error message remained usable.

Describe feedback from real participants accurately. A small qualitative review is not a representative readability study. Document the limits of the finding as well as the improvement it suggests.

13. Connect language, wrapping and editorial maintenance

Long words are ordinary in many specialist texts, particularly German. Provide suitable wrapping opportunities. Artificial breaks inserted into stored titles need care because those titles may also appear in search previews, emails or translations where the break is inappropriate.

The document language helps browsers and assistive technologies interpret content. An English version needs a suitable English language declaration, while a differently worded passage can be marked individually. This does not replace translation quality, but establishes a more accurate technical context.

Automatic hyphenation can help, but review its actual rendering in supported browsers. Dictionaries and language support may differ. A CSS declaration alone does not prove that every difficult title wraps comfortably.

Very long technical strings such as paths and addresses need appropriate overflow or wrapping. Do not silently remove meaningful characters. Horizontal scrolling within a code region can be preferable to breaks that obscure the relationship between lines.

Editorial work contributes too. An unwieldy heading should not be forced to fit only by making it progressively smaller. Ask whether the same meaning can be expressed more precisely. Review the decision across the language versions afterwards.

Add new real difficulties to the specimen. An unusually long product name or a newly supported currency may create an additional requirement. The type system can then develop around observed tasks rather than losing its rules with every content addition.

14. A typography acceptance checklist

• Text types, languages and special characters are recorded.
• The font has been reviewed with real content in a browser.
• Similar letters and numbers remain distinguishable.
• Body size, measure and leading work together.
• Type levels have understandable roles.
• Emphasis and link styling remain unambiguous.
• Table values have suitable alignment and labels.
• Enlargement does not clip information.
• Fallback rendering and slow loading have been checked.
• Personal spacing adjustments remain usable.
• Font licensing and delivered files are documented.
• A later font change repeats the same review cases.

Common typography questions

Are serif typefaces inherently less readable?

That generalisation is not useful for selection. Typeface design, size, content and reading conditions need to be assessed together.

Does a professional website need several font families?

No. One suitable family may cover many tasks. An additional family needs a specific design purpose and suitable licensing.

Is font-display: swap always best?

The choice depends on actual loading behaviour and the intended treatment of fallback rendering. Check visibility and layout changes with the real files.

Sources and related foundations

The linked W3C WAI documents, MDN reference and web.dev guide were checked on 9 November 2026. The selection workflow, specimen and examples are original editorial tools.

Continue with Semantic HTML, Loading performance and user experience and Requirements for business websites.