Variable Fonts in 60 Seconds
One file, infinite weights. Here's why variable fonts are the future.
Traditional font families ship as separate files — one for regular, one for bold, one for light, and so on. Each weight adds bytes to your page load.
Variable fonts package every weight, width and slant into a single file. You get the entire spectrum, often for less weight than two static files combined.
On the web, this means you can set CSS like font-weight: 437 if you want, and you'll get exactly that weight. You can animate weight smoothly. You can show a unique weight per breakpoint.
The result is richer typography with smaller page weight. If you're picking a new font in 2025, choosing a variable version is almost always the right call.
Why this matters
Most teams underestimate how much typography shapes their work. A small change in size, weight or spacing rewires the perceived tone of an entire screen. Variable Fonts in 60 Seconds is one of those areas where a little knowledge goes a very long way, especially once you start applying it across performance, rendering and delivery on real browsers.
Designers, founders and developers all benefit from getting this right. A quick spin through the font-display CSS spec is usually enough to see how much variety there is between families that look superficially similar — and how much that variety changes the feel of a finished interface.
The mistake is treating typography decisions as one-off choices. In reality they compound. The font you pick today drives the rhythm of every screen, every email and every PDF you ship for the next several years. the font-display CSS spec is a good outside read on why those early calls matter so much.
A worked example
Think of a developer-tools website. The audience is technical, the screenshots are dense, and trust signals matter as much as visual polish.
Applying the ideas from Variable Fonts in 60 Seconds starts with a single decision and ripples outward. You pick a primary family — often something proven like the font-display CSS spec — lock in a small set of weights, and define how those weights map to roles in the interface. Headlines get one weight, body another, captions a third. Nothing else is allowed without an explicit reason.
From there you tune the scale. Set a comfortable body size for your audience — usually 16 to 18 pixels on the web, larger on long-form sites — and build a modular scale upward. Use weight and colour to handle secondary hierarchy instead of inventing new sizes. The result feels disciplined without feeling rigid.
Finally, test in context. Open the design at multiple viewports, in light and dark modes, with realistic content rather than lorem ipsum. If a candidate fails the real-content test, swap it for an alternative from the font-display CSS spec and try again — typography decisions that look elegant in a Figma mockup sometimes collapse the moment real headlines arrive.
Common pitfalls
Once you start paying attention, the same handful of mistakes show up in almost every project that drifted off course. They are easy to fix once you notice them, and even easier to avoid the next time — and CSS-Tricks on web fonts catalogues several of them with examples worth bookmarking.
Mixing too many families. Two is usually plenty; three is occasionally justified; four is almost always a mistake. The more families you add, the more accidental visual noise you create.
Forgetting about numerics. Tabular figures keep tables aligned; proportional figures look better in running text. Most quality families ship both, and most designers never switch them on.
Loading too many weights. Every additional file slows the page and dilutes the system. Audit your real usage and cut anything you cannot point to in a layout.
None of these pitfalls are dramatic on their own. The trouble is that they accumulate quietly until one day the design feels tired and nobody can point to a single reason why. A short, regular audit catches all of them.
A quick checklist
Before you ship the next iteration of your design, run through a short checklist. It takes five minutes and prevents most of the typography regressions that creep in over time.
First, count your fonts. If you cannot justify every family and every weight in one sentence, remove the ones you cannot defend — Zach Leatherman's font loading guide is a useful reference to sanity-check what each family actually offers. Second, verify your hierarchy by squinting at a representative screen — the most important element should still be the most prominent, even at low fidelity.
Third, check the long content. Open the longest paragraph in the product and read it out loud. If you stumble, the line-height, measure or size is probably wrong. Fourth, test at extremes — the longest possible heading, the shortest possible label, an empty state, a localized translation. Typography that survives the extremes survives everything else.
Fifth and last, make sure the system is documented. A single page that lists your fonts, weights, sizes and rules saves more design time than any tool — CSS-Tricks on web fonts has a thoughtful take on writing those rules down without turning the doc into a chore.
Where this fits in a system
In a mature design system, typography is one of the first tokens to stabilise and one of the last to get revisited. That makes sense — once your team has agreed on a scale and a set of roles, those decisions touch every product surface and every channel. They become part of performance, rendering and delivery on real browsers rather than a layer painted on top.
Tokens give you the leverage. Instead of hard-coding pixel sizes everywhere, you define a token like text-body or text-heading-lg and let components reference it. When you decide to bump body up by one step — or swap the underlying family for something from the Variable Fonts site — you change one number and ship.
Roles matter more than sizes. Two tokens that happen to be the same size today might diverge tomorrow because they represent different intentions. Naming by role — caption, body, lede, headline — protects you from the temptation to merge them whenever the numbers happen to align.
Finally, write down the why. A token system without documentation eventually drifts. A token system with a paragraph next to each entry survives team changes, redesigns and rebrands.
Wrapping up
Variable Fonts in 60 Seconds rewards the people who slow down long enough to think about it. The principles are not complicated, the vocabulary is small, and the payoff is a body of work that reads as more considered than the average.
If you take only one thing away, make it this: typography is a long game. Every page you ship trains the audience to recognise your voice, and every inconsistency erodes that recognition a little. Pick a system — there are plenty of starting points in the font-display CSS spec — document it, and resist the urge to deviate without a real reason.
Treat each new project as a chance to tighten the system rather than start from scratch. Over time your typography stops being a collection of choices and starts being a stable craft — something a team can build on instead of relitigating every quarter.
Further reads
Six more posts to dig into next.
- Web6 min
Tool spotlight: Fontsource
NPM packages for self-hosting hundreds of open-source fonts with one import.
- Web6 min
Tool spotlight: Utopia.fyi
Fluid-typography calculator with sensible defaults for responsive design.
- Web6 min
Tool spotlight: Better Web Type
Short, focused web-typography courses aimed at developers.
- Web6 min
Tool spotlight: Web Font Loader
The original asynchronous font loader; still useful for legacy stacks.
- Web6 min
Tool spotlight: Fontaine
Generates fallback fonts that match metrics to reduce CLS dramatically.
- Web6 min
Tool spotlight: Capsize
Crop white space above and below text using actual font metrics.