Web Typography: A Complete Guide for 2026

Good web typography is what makes a page feel effortless to read — and almost no one notices it when it’s working. The job is to set type that stays legible across phones, laptops, and 4K monitors, loads fast, respects accessibility, and carries your brand without fighting the reader. This guide covers the whole system: choosing typefaces, building a type scale, loading fonts without layout shift, setting line height and spacing, and shipping all of it accessibly. It’s the canonical reference for the topic on this site, and it links down to deeper guides on every sub-topic as you need them.

If you want to skip to a specific piece, jump to our companion guides on font sizes for the web, responsive and fluid typography, line height and letter spacing, Google Fonts versus self-hosting, and kerning, tracking, and leading. For choosing typefaces, our font pairing guide and font licensing guide cover the rest.

What web typography actually is

Web typography is the practice of setting text in a browser so it’s legible, accessible, fast, and on-brand. It overlaps with print typography on the fundamentals — hierarchy, rhythm, contrast — but adds constraints that don’t exist on paper: the reader controls the viewport size, the zoom level, the device, and sometimes the font itself. You don’t get to fix a layout the way you would in a print PDF. Instead you define rules in CSS and let the browser render them across an enormous range of conditions.

That shift in control is the whole game. Print typographers optimize one fixed canvas; web typographers design a system that degrades gracefully. Everything below is about building that system deliberately rather than letting browser defaults decide for you.

Choosing typefaces for the screen

Not every typeface survives a screen. Fonts drawn for print often have delicate serifs and high stroke contrast that turn muddy at small pixel sizes. For body text especially, pick faces designed or hinted for screens.

Reliable, free, screen-first choices in 2026:

• Inter — the default modern UI workhorse. Tall x-height, wide language coverage, a true variable font, and excellent legibility from 14px up. Free, open-source (SIL Open Font License).
• Source Sans 3 and Source Serif 4 — Adobe’s open superfamily; calm, neutral, and reliable for body copy.
• Work Sans — optimized for on-screen reading at text sizes; slightly warmer than Inter.
• Lora — a readable, screen-tuned serif for editorial body text and blog content.
• IBM Plex — a full superfamily (Sans, Serif, Mono) when you want guaranteed harmony across roles.

For headlines you have more freedom — display faces can carry contrast and character because they appear large and briefly. Just keep the body face conservative. Pairing the two well is its own discipline; see the font pairing guide for the rules and tested combinations. Whatever you choose, confirm you’re allowed to embed it on a website — desktop licenses don’t cover @font-face by default, which is exactly what our font licensing guide walks through.

Building a type scale

A type scale is the set of sizes you allow on the page — H1 down to captions — chosen with a consistent ratio so the hierarchy feels intentional rather than arbitrary. Pick a base body size (usually 16px / 1rem) and multiply up by a ratio for each heading level.

Common ratios and their feel:

Ratio	Name	Feel
1.200	Minor third	Tight, restrained — good for dense UI and dashboards
1.250	Major third	Balanced default for content sites
1.333	Perfect fourth	Confident, editorial — strong headline contrast
1.500	Perfect fifth	Dramatic, marketing-page energy

Define the scale once as CSS custom properties and reference them everywhere, so a size never gets invented inline:

• --step-0: 1rem; (body)
• --step-1: 1.25rem; (H4 / lead)
• --step-2: 1.563rem; (H3)
• --step-3: 1.953rem; (H2)
• --step-4: 2.441rem; (H1)

Express sizes in rem rather than px so the whole scale respects the user’s browser font-size setting — a basic but frequently broken accessibility requirement. We cover the size question in depth in the web font size guide.

Fluid and responsive type

A fixed scale that looks right on a laptop is often too big on a phone and too small on a large monitor. The modern fix is fluid typography: sizes that scale smoothly with the viewport using CSS clamp(), so you set a minimum, a preferred (viewport-relative) value, and a maximum, and the browser interpolates between them.

A single declaration like font-size: clamp(2rem, 1.5rem + 2.5vw, 3rem); gives a headline that’s never smaller than 32px, never larger than 48px, and scales fluidly in between — no media-query breakpoints required. This is the biggest shift in web typography over the last few years, and it deserves its own treatment: see responsive typography: fluid type for every screen for the full clamp() method, viewport-unit math, and accessibility caveats (always include a rem term so zoom still works).

Line height, measure, and letter spacing

Type choice and size only get you halfway. Reading comfort is mostly governed by three relationships:

• Line height (leading) — for body text, set line-height between 1.4 and 1.6 (unitless, so it scales with font size). Tighten to roughly 1.1–1.25 for large headlines, which need less breathing room.
• Measure (line length) — aim for 60–75 characters per line for body copy. Control it with max-width in ch units (e.g. max-width: 68ch;). Lines that run the full width of a desktop are the single most common readability failure on the web.
• Letter spacing (tracking) — leave body text alone; the type designer already spaced it. Add small positive tracking to all-caps and small text; consider slight negative tracking on large display headings.

These three interact — tighter leading needs a shorter measure, and so on. The full set of rules, with numbers, lives in line height and letter spacing: readability best practices, and the finer distinctions between kerning, tracking, and leading are covered in the typography spacing guide.

Loading fonts without breaking the page

Web fonts are render-blocking dependencies. Load them carelessly and you get invisible text, layout shift, or a slow first paint. The essentials:

• Ship WOFF2. It’s the smallest, best-compressed format and is supported by every browser you should care about in 2026. You don’t need WOFF or TTF fallbacks for the modern web.
• Use font-display: swap so text renders immediately in a fallback and swaps when the web font arrives — no invisible-text period.
• Subset aggressively. If you only need Latin, strip the rest. A subset Inter file can drop from hundreds of KB to tens.
• Preload your critical font with <link rel="preload" as="font" type="font/woff2" crossorigin> so the browser fetches it early.
• Match fallback metrics using size-adjust, ascent-override, and friends to minimize the layout shift when the real font swaps in.

Where you host those files — Google’s CDN versus your own server — affects both speed and privacy, and the answer changed with GDPR enforcement. We weigh it fully in Google Fonts versus self-hosted fonts.

Variable fonts

A variable font packs an entire family — every weight, and often width and optical size — into a single file you control through CSS axes. Instead of loading separate files for Regular, Medium, and Bold, you ship one file and request font-weight: 540 or any value on the axis. The practical wins: fewer requests, smaller total payload, and access to in-between weights and true optical sizing. Inter, Fraunces, and Source Serif 4 are all excellent variable fonts. In 2026, default to a variable font whenever the family offers one.

Accessible typography

Accessibility isn’t a separate pass — it’s baked into the choices above. The non-negotiables:

• Respect user zoom. Size everything in rem/em so text scales when a user increases their browser font size or zooms to 200%, as WCAG requires.
• Maintain contrast. Body text needs at least a 4.5:1 contrast ratio against its background (3:1 for large text). Light-gray-on-white body copy is a frequent failure.
• Don’t justify body text on the web — browser justification creates uneven “rivers” of white space without the hyphenation engine print uses. Left-align.
• Keep a comfortable measure and leading — the same 60–75 characters and 1.5 line height that aid everyone help readers with dyslexia and low vision most.
• Honor prefers-reduced-motion if you animate type.

A practical web typography workflow

Pulling it together, here’s the order pros work in rather than tweaking values at random:

1. Pick the body face first. It carries the most words and the most risk — choose a proven screen face like Inter or Source Serif 4 before anything else.
2. Set the base size and scale. Lock 16px/1rem body and a ratio; define the scale as custom properties.
3. Add a headline face and pair it deliberately for contrast and shared DNA.
4. Make it fluid. Convert headline steps to clamp() so the scale breathes across viewports.
5. Tune leading and measure. 1.5 line height, 60–75ch, comfortable paragraph spacing.
6. Optimize loading. WOFF2, subset, font-display: swap, preload, fallback-metric overrides.
7. Audit accessibility. Zoom to 200%, check contrast, confirm nothing breaks.

Do these in order and the page reads well on day one instead of after a month of fiddling.

Common web typography mistakes

• Body text under 16px. Comfortable reading on screens starts at 16px; smaller is a tax on every visitor.
• Full-width lines. No max-width on text blocks, so lines run 120+ characters on desktop.
• Pixel-locked sizing. Hard px values that ignore the user’s font-size preference.
• Too many fonts and weights. Each adds payload; restraint is faster and cleaner.
• Layout shift on font load. No font-display strategy and no metric overrides.
• Low-contrast gray text. Trendy and unreadable; check the ratio.

Frequently Asked Questions

What is web typography?

Web typography is the practice of setting text in a browser so it’s legible, accessible, fast, and on-brand. It covers choosing screen-suitable typefaces, building a type scale, sizing and spacing text with CSS, and loading web fonts efficiently across every device and viewport a visitor might use.

What font size should body text be on the web?

Use at least 16px (1rem) for body text; many sites go to 17–18px for comfort. Always size in rem rather than fixed pixels so text respects the user’s browser settings and zoom. See our web font size guide for headings, captions, and accessibility details.

Should I use Google Fonts or self-host fonts?

Self-hosting is usually faster and privacy-safer in 2026 because Google Fonts’ CDN no longer caches across sites and serving from your own domain avoids third-party requests and GDPR concerns. Google Fonts is fine for prototypes and simple sites. Our dedicated comparison covers the trade-offs in full.

What is fluid typography?

Fluid typography scales text smoothly with the viewport using CSS clamp(), which sets a minimum, a viewport-relative preferred value, and a maximum. It removes the need for size breakpoints and keeps type proportional from phone to large monitor — just keep a rem term so zoom still works.

What line height is best for web body text?

Set a unitless line-height between 1.4 and 1.6 for body copy — 1.5 is a safe default — so spacing scales with font size. Tighten to roughly 1.1–1.25 for large headlines. Pair it with a 60–75 character measure for the most comfortable reading.

Try it live: Use our free type scale calculator to generate a modular font-size scale and copy the CSS variables.