Type on the Web
The web doesn’t hold still — so your type has to be engineered, not just designed.
Print sets type once, at a fixed size, on a fixed page. The web sets it on every screen at once, while the user resizes, zooms, and brings their own settings. Good web typography is the same craft from the other modules plus a layer of engineering: fluid sizing, font loading, and respecting the reader’s machine.
Get the engineering wrong and even perfect type arrives slow, jumpy, or locked to your assumptions instead of the reader’s.
One size for every screen
A headline that’s right on a desktop is often too big on a phone — and stacking breakpoints to fix it is clumsy. clamp() solves it in one line: give a minimum size, a maximum size, and a preferred value that scales with the viewport, and the browser fluidly interpolates between them.
No media-query steps, no jumps — the type just breathes with the screen. Build the exact function below.
Size in rem, not px
A reader can set a larger default font size in their browser — often because they genuinely need it. Size your text in rem and it scales from that preference; hard-code px and it quietly ignores them.
It isn’t a WCAG failure — page zoom still works either way — but it’s a courtesy that costs nothing and respects a setting the reader chose on purpose. Use rem for type, reserve px for hairline borders.
The moment the font arrives
Web fonts download after the HTML, so there’s a gap. How you handle it is a real design decision. font-display: swap shows readable fallback text instantly, then swaps when the font lands — a small reflow, but the words are never invisible. block hides the text first, risking a blank flash.
Budget your weights, too: every weight is a download. Self-host modern .woff2 files, preload the critical one, and don’t ship eight weights you use twice.
Many weights, one file
A variable font packs a whole range — every weight, sometimes width and slant too — into a single file you can set to any value in between. One download replaces the five or six static weights you’d otherwise ship.
For the web that’s a double win: fewer requests and smaller payload, plus the freedom to fine-tune weight fluidly (even animate it). Variable fonts are quietly becoming the default infrastructure of web type.
Fast type vs slow type
Same words, two loading strategies — one respects the reader’s connection, one punishes it.
self-hosted + preloaded
font-display: swap
A single self-hosted variable font, preloaded, swapping in instantly. Text is readable from the first paint.
third-party host
font-display: block
Eight static weights from a third party, blocking render. A blank flash, then a heavy payload — on mobile data, painful.
The web layer doesn’t change what good type is — it changes how you deliver it. Your scale becomes clamp(), your weights become a font-loading budget, your sizes become rem so the reader’s settings win. The craft is the same; the engineering is what keeps it intact across a million different screens.
The Web Type glossary
Six terms for shipping type that loads fast and scales clean. Tap a card to flip it.
Questions you actually ask
Debug the delivery
Mixed formats — multiple choice, multi-correct, fill-in, match, order, read-think-connect and write-your-own — each with layered hints: a nudge, the reasoning, then a deeper connection. Served from the question bank, never hardcoded.